<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en"><head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
   <title>Uniform Resource Identifier (URI): Generic Syntax</title><style type="text/css" title="Xml2Rfc (sans serif)">
a {
  text-decoration: none;
}
a:hover {
  text-decoration: underline;
}
a:active {
  text-decoration: underline;
}
body {
  
  color: #000000;
  font-family: verdana, helvetica, arial, sans-serif;
  font-size: 10pt;
}
dl {
  margin-left: 2em;
}
h1 {
  color: #333333;
  font-size: 14pt;
  line-height: 21pt;
  page-break-after: avoid;
}
h1.np {
  page-break-before: always;
}
h1 a {
  color: #333333;
}
h2 {
  color: #000000;
  font-size: 12pt;
  line-height: 15pt;
  page-break-after: avoid;
}
h2 a {
  color: #000000;
}
h3 {
  color: #000000;
  font-size: 10pt;
  page-break-after: avoid;
}
h3 a {
  color: #000000;
}
h4 {
  color: #000000;
  font-size: 10pt;
  page-break-after: avoid;
}
h4 a {
  color: #000000;
}
h5 {
  color: #000000;
  font-size: 10pt;
  page-break-after: avoid;
}
h5 a {
  color: #000000;
}
img {
  margin-left: 3em;
}
li {
  margin-left: 2em;
  margin-right: 2em;
}
ol {
  margin-left: 2em;
  margin-right: 2em;
}
p {
  margin-left: 2em;
  margin-right: 2em;
}
pre {
  margin-left: 3em;
  background-color: lightyellow;
}
table {
  margin-left: 2em;
}
table.header {
  width: 95%;
  font-size: 10pt;
  color: white;
}
td.top {
  vertical-align: top;
}
td.topnowrap {
  vertical-align: top;
  white-space: nowrap; 
}
td.right {
  text-align: right;
}
td.header-l {
  background-color: gray;
  width: 50%;
}
td.header-r {
  background-color: gray;
  width: 50%;
  text-align: right;
}
thead {
  display:table-header-group;
}
ul.toc {
  list-style: none;
  margin-left: 2em;
  margin-right: 0em;
  padding-left: 0em;
}
li.tocline0 {
  line-height: 150%;
  font-weight: bold;
  font-size: 10pt;
  margin-left: 0em;
  margin-right: 0em;
}
li.tocline1 {
  line-height: normal;
  font-weight: normal;
  font-size: 9pt;
  margin-left: 0em;
  margin-right: 0em;
}
li.tocline2 {
  font-size: 0pt;
}
ul.ind {
  list-style: none;
  margin-left: 1.5em;
  margin-right: 0em;
  padding-left: 0em;
}
li.indline0 {
  font-weight: bold;
  line-height: 200%;
  margin-left: 0em;
  margin-right: 0em;
}
li.indline1 {
  font-weight: normal;
  line-height: 150%;
  margin-left: 0em;
  margin-right: 0em;
}
.comment {
  background-color: yellow;
}
.editingmark {
  background-color: khaki;
}
.error {
  font-size: 14pt;
  background-color: red;
}
.toowide {
  color: red;
  font-weight: bold;
}
.title {
  color: #990000;
  font-size: 18pt;
  line-height: 18pt;
  font-weight: bold;
  text-align: center;
}
.figure {
  font-weight: bold;
  text-align: center;
  font-size: 9pt;
}
.filename {
  color: #333333;
  font-weight: bold;
  font-size: 12pt;
  line-height: 21pt;
  text-align: center;
}
.warning {
  font-size: 14pt;
  background-color: yellow;
}
del {
  color: red;
  text-decoration: line-through;
}
.del {
  color: red;
  text-decoration: line-through;
}
ins {
  color: green;
  text-decoration: underline;
}
.ins {
  color: green;
  text-decoration: underline;
}
.pn {
  position: absolute;
  color: white;
}
.pn:hover {
  color: #C8A8FF;
}

table.openissue {
  background-color: khaki;
  border-width: thin;
  border-style: solid;
  border-color: black;
}

table.closedissue {
  background-color: white;
  border-width: thin;
  border-style: solid;
  border-color: gray;
  color: gray; 
}

.closed-issue {
  border: solid;
  border-width: thin;
  background-color: lime;
  font-size: smaller;
  font-weight: bold;
}

.open-issue {
  border: solid;
  border-width: thin;
  background-color: red;
  font-size: smaller;
  font-weight: bold;
}

.editor-issue {
  border: solid;
  border-width: thin;
  background-color: yellow;
  font-size: smaller;
  font-weight: bold;
}

@media print {
  .noprint {
    display: none;
  }
  
  table.header {
    width: 90%;
  }

  td.header-l {
    width: 50%;
    color: black;
    background-color: white;
    vertical-align: top;
    font-size: 10pt;
  }

  td.header-r {
    width: 33%;
    color: black;
    background-color: white;
    vertical-align: top;
    text-align: right;
    font-size: 10pt;
  }

  ul.toc a::after {
    content: leader('.') target-counter(attr(href), page);
  }
  
  a.iref {
    content: target-counter(attr(href), page);
  }
}

@page {
  @top-left {
       content: "RFC 3986"; 
  } 
  @top-right {
       content: "January 2005"; 
  } 
  @top-center {
       content: "URI Generic Syntax"; 
  } 
  @bottom-left {
       content: "Berners-Lee, et al."; 
  } 
  @bottom-center {
       content: "Standards Track"; 
  } 
  @bottom-right {
       content: "[Page " counter(page) "]"; 
  } 
}

@page:first { 
    @top-left {
      content: normal;
    }
    @top-right {
      content: normal;
    }
    @top-center {
      content: normal;
    }
}
</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Characters" href="#rfc.section.2"><link rel="Chapter" title="3 Syntax Components" href="#rfc.section.3"><link rel="Chapter" title="4 Usage" href="#rfc.section.4"><link rel="Chapter" title="5 Reference Resolution" href="#rfc.section.5"><link rel="Chapter" title="6 Normalization and Comparison" href="#rfc.section.6"><link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7"><link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"><link rel="Chapter" title="9 Acknowledgements" href="#rfc.section.9"><link rel="Chapter" href="#rfc.section.10" title="10 References"><link rel="Appendix" title="A Collected ABNF for URI" href="#rfc.section.A"><link rel="Appendix" title="B Parsing a URI Reference with a Regular Expression" href="#rfc.section.B"><link rel="Appendix" title="C Delimiting a URI in Context" href="#rfc.section.C"><link rel="Appendix" title="D Changes from RFC 2396" href="#rfc.section.D"><link rel="Alternate" title="Authorative ASCII version" href="http://www.ietf.org/rfc/rfc3986"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.22, 2005/02/09 02:33:51, XSLT vendor: SAXON 7.8 from Michael Kay http://saxon.sf.net/"><meta name="keywords" content="uniform resource identifier, URI, URL, URN, WWW, resource"><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"><meta name="DC.Creator" content="Berners-Lee, T."><meta name="DC.Creator" content="Fielding, R."><meta name="DC.Creator" content="Masinter, L."><meta name="DC.Identifier" content="urn:ietf:rfc:3986"><meta name="DC.Date.Issued" scheme="ISO8601" content="2005-01"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2732"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2396"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:1808"><meta name="DC.Description.Abstract" content="A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme."><style rel="stylesheet" id="" type="text/css" charset="utf-8">SPAN.skype_pnh_container SPAN.skype_pnh_mark{  display:none !important;}@media screen{SPAN.skype_pnh_print_container{  display:none !important;}SPAN.skype_pnh_container, SPAN.skype_pnh_container *{background-attachment: scroll !important;background-color: transparent !important;background-image: none !important;background-position: 0px 0px ! important;background-repeat: no-repeat !important;border: 0px none !important;border-color: #000000 !important;border-style: none !important;border-width: 0 !important;border-left: 0 none #000000 !important;border-top: 0 none #000000 !important;border-right: 0 none #000000 !important;border-bottom: 0 none #000000 !important;border-left-color: #000000 !important;border-left-style: none !important;border-left-width: 0 !important;border-top-color: #000000 !important;border-top-style: none !important;border-top-width: 0 !important;border-right-color: #000000 !important;border-right-style: none !important;border-right-width: 0 !important;border-bottom-color: #000000 !important;border-bottom-style: none !important;border-bottom-width: 0 !important;border-collapse: separate !important;bottom: auto !important;clear: none !important;clip: auto !important;cursor: pointer !important;direction: ltr !important;display: inline !important;float: none !important;font-style: normal !important;left: auto !important;letter-spacing: 0 !important;list-style-image: none !important;list-style-position: outside !important;list-style-type: disc !important;overflow: hidden !important;overflow-x: hidden !important;overflow-y: hidden !important;padding: 0px 0px 0px 0px !important;padding-left: 0px !important;padding-top: 0px !important;padding-right: 0px !important;padding-bottom: 0px !important;page-break-after: auto !important;page-break-before: auto !important;page-break-inside: auto !important;position: static !important;right: auto !important;table-layout: auto !important;text-align: left !important;text-decoration: none !important;text-indent: 0px !important;text-transform: none !important;top: auto !important;voice-family: inherit !important;white-space: nowrap !important;word-spacing: normal !important;z-index: 0 !important;  color: #49535A !important;  font-family: Tahoma, Arial, Helvetica, sans-serif !important;  font-size: 11px !important;  font-weight: bold !important;  height: 14px !important;  line-height: 14px !important;  margin-left: 0px !important;  margin-top: 0px !important;  margin-right: 0px !important;  margin-bottom: 0px !important;  vertical-align: baseline !important;  width: auto !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_fax SPAN.skype_pnh_right_span, SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_fax SPAN.skype_pnh_right_span{  background-position: -92px 0px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_free SPAN.skype_pnh_dropart_flag_span{  background-position: 0px 1px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_free SPAN.skype_pnh_textarea_span{  background-position: -90px 0px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_free SPAN.skype_pnh_text_span{  visibility: hidden !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_free SPAN.skype_pnh_dropart_flag_span{  background-position: 0px 1px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_free SPAN.skype_pnh_textarea_span{  background-position: -160px 0px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_free SPAN.skype_pnh_text_span{  background-position: -160px 0px !important;  color: #FFFFFF !important;}SPAN.skype_pnh_container SPAN.skype_pnh_left_span{  background-position: 0px 0px !important;  width: 6px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_dropart_span{  background-position: -11px 0px !important;  width: 27px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_dropart_wo_arrow_span{  background-position: -130px 0px !important;  width: 18px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_dropart_flag_span{  background-position: 1px 1px !important;  width: 18px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_textarea_span{  background-position: -125px 0px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_text_span{  padding-left: 5px !important;  background-position: -125px 0px !important;}SPAN.skype_pnh_container SPAN.skype_pnh_right_span{  background-position: -62px 0px !important;  width: 15px !important;}}@media print{SPAN.skype_pnh_print_container{}SPAN.skype_pnh_container{    display:none !important;}}@media screen{SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_common *{  background-image:url('chrome://skype_ff_extension/skin/numbers_common_inactive_icon_set.gif') !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_common *{  background-image:url('chrome://skype_ff_extension/skin/numbers_common_active_icon_set.gif') !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_fax *{  background-image:url('chrome://skype_ff_extension/skin/numbers_common_inactive_icon_set.gif') !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_fax *{  background-image:url('chrome://skype_ff_extension/skin/numbers_common_active_icon_set.gif') !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_free SPAN.skype_pnh_text_span{  background-image: none !important;  color: transparent !important;  visibility: visible !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_inactive_free *{  background-image:url('chrome://skype_ff_extension/skin/numbers_free_icon_set.gif') !important;}SPAN.skype_pnh_container SPAN.skype_pnh_highlighting_active_free *{  background-image:url('chrome://skype_ff_extension/skin/numbers_free_icon_set.gif') !important;}SPAN.skype_pnh_container SPAN.skype_pnh_dropart_flag_span{  background-image: url('chrome://skype_ff_extension/skin/flags.gif') !important;}}</style></head><body><table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"><tbody><tr><td class="header-l">Network Working Group&nbsp;</td><td class="header-r">T. Berners-Lee&nbsp;</td></tr><tr><td class="header-l">Request for Comments: 3986&nbsp;</td><td class="header-r">W3C/MIT&nbsp;</td></tr><tr><td class="header-l">Obsoletes: <a href="http://www.ietf.org/rfc/rfc2732.txt">2732</a>,
      <a href="http://www.ietf.org/rfc/rfc2396.txt">2396</a>,
      <a href="http://www.ietf.org/rfc/rfc1808.txt">1808</a>&nbsp;</td><td class="header-r">R. Fielding&nbsp;</td></tr><tr><td class="header-l">STD: 66&nbsp;</td><td class="header-r">Day Software&nbsp;</td></tr><tr><td class="header-l">Updates: <a href="http://www.ietf.org/rfc/rfc1738.txt">1738</a>&nbsp;</td><td class="header-r">L. Masinter&nbsp;</td></tr><tr><td class="header-l">Category: Standards Track&nbsp;</td><td class="header-r">Adobe Systems&nbsp;</td></tr><tr><td class="header-l">&nbsp;</td><td class="header-r">January 2005&nbsp;</td></tr></tbody></table><p class="title"><br>Uniform Resource Identifier (URI): Generic Syntax</p><h1><a name="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This
 document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the “Internet 
Official Protocol Standards” (STD 1) for the standardization state and 
status of this protocol. Distribution of this memo is unlimited.</p><h1><a name="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright © The Internet Society (2005). All Rights Reserved.</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> <p>A
 Uniform Resource Identifier (URI) is a compact sequence of characters 
that identifies an abstract or physical resource. This specification 
defines the generic URI syntax and a process for resolving URI 
references that might be in relative form, along with guidelines and 
security considerations for the use of URIs on the Internet. The URI 
syntax defines a grammar that is a superset of all valid URIs, allowing 
an implementation to parse the common components of a URI reference 
without knowing the scheme-specific requirements of every possible 
identifier. This specification does not define a generative grammar for 
URIs; that task is performed by the individual specifications of each 
URI scheme.</p><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li class="tocline0">1.&nbsp;&nbsp;&nbsp;<a href="#intro">Introduction</a><ul class="toc"><li class="tocline1">1.1.&nbsp;&nbsp;&nbsp;<a href="#overview">Overview of URIs</a><ul class="toc"><li class="tocline1">1.1.1.&nbsp;&nbsp;&nbsp;<a href="#generic-syntax">Generic Syntax</a></li><li class="tocline1">1.1.2.&nbsp;&nbsp;&nbsp;<a href="#examples">Examples</a></li><li class="tocline1">1.1.3.&nbsp;&nbsp;&nbsp;<a href="#URLvsURN">URI, URL, and URN</a></li></ul></li><li class="tocline1">1.2.&nbsp;&nbsp;&nbsp;<a href="#design">Design Considerations</a><ul class="toc"><li class="tocline1">1.2.1.&nbsp;&nbsp;&nbsp;<a href="#transcription">Transcription</a></li><li class="tocline1">1.2.2.&nbsp;&nbsp;&nbsp;<a href="#identification">Separating Identification from Interaction</a></li><li class="tocline1">1.2.3.&nbsp;&nbsp;&nbsp;<a href="#hierarchical">Hierarchical Identifiers</a></li></ul></li><li class="tocline1">1.3.&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li></ul></li><li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#characters">Characters</a><ul class="toc"><li class="tocline1">2.1.&nbsp;&nbsp;&nbsp;<a href="#percent-encoding">Percent-Encoding</a></li><li class="tocline1">2.2.&nbsp;&nbsp;&nbsp;<a href="#reserved">Reserved Characters</a></li><li class="tocline1">2.3.&nbsp;&nbsp;&nbsp;<a href="#unreserved">Unreserved Characters</a></li><li class="tocline1">2.4.&nbsp;&nbsp;&nbsp;<a href="#when-to-percent-encode">When to Encode or Decode</a></li><li class="tocline1">2.5.&nbsp;&nbsp;&nbsp;<a href="#identifying-data">Identifying Data</a></li></ul></li><li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#components">Syntax Components</a><ul class="toc"><li class="tocline1">3.1.&nbsp;&nbsp;&nbsp;<a href="#scheme">Scheme</a></li><li class="tocline1">3.2.&nbsp;&nbsp;&nbsp;<a href="#authority">Authority</a><ul class="toc"><li class="tocline1">3.2.1.&nbsp;&nbsp;&nbsp;<a href="#userinfo">User Information</a></li><li class="tocline1">3.2.2.&nbsp;&nbsp;&nbsp;<a href="#host">Host</a></li><li class="tocline1">3.2.3.&nbsp;&nbsp;&nbsp;<a href="#port">Port</a></li></ul></li><li class="tocline1">3.3.&nbsp;&nbsp;&nbsp;<a href="#path">Path</a></li><li class="tocline1">3.4.&nbsp;&nbsp;&nbsp;<a href="#query">Query</a></li><li class="tocline1">3.5.&nbsp;&nbsp;&nbsp;<a href="#fragment">Fragment</a></li></ul></li><li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#usage">Usage</a><ul class="toc"><li class="tocline1">4.1.&nbsp;&nbsp;&nbsp;<a href="#uri-reference">URI Reference</a></li><li class="tocline1">4.2.&nbsp;&nbsp;&nbsp;<a href="#relative-ref">Relative Reference</a></li><li class="tocline1">4.3.&nbsp;&nbsp;&nbsp;<a href="#absolute-uri">Absolute URI</a></li><li class="tocline1">4.4.&nbsp;&nbsp;&nbsp;<a href="#same-document">Same-Document Reference</a></li><li class="tocline1">4.5.&nbsp;&nbsp;&nbsp;<a href="#suffix">Suffix Reference</a></li></ul></li><li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#reference-resolution">Reference Resolution</a><ul class="toc"><li class="tocline1">5.1.&nbsp;&nbsp;&nbsp;<a href="#base-uri">Establishing a Base URI</a><ul class="toc"><li class="tocline1">5.1.1.&nbsp;&nbsp;&nbsp;<a href="#base-content">Base URI Embedded in Content</a></li><li class="tocline1">5.1.2.&nbsp;&nbsp;&nbsp;<a href="#base-encapsulated">Base URI from the Encapsulating Entity</a></li><li class="tocline1">5.1.3.&nbsp;&nbsp;&nbsp;<a href="#base-retrieval">Base URI from the Retrieval URI</a></li><li class="tocline1">5.1.4.&nbsp;&nbsp;&nbsp;<a href="#base-default">Default Base URI</a></li></ul></li><li class="tocline1">5.2.&nbsp;&nbsp;&nbsp;<a href="#absolutize">Relative Resolution</a><ul class="toc"><li class="tocline1">5.2.1.&nbsp;&nbsp;&nbsp;<a href="#relative-base">Pre-parse the Base URI</a></li><li class="tocline1">5.2.2.&nbsp;&nbsp;&nbsp;<a href="#relative-transform">Transform References</a></li><li class="tocline1">5.2.3.&nbsp;&nbsp;&nbsp;<a href="#relative-merge">Merge Paths</a></li><li class="tocline1">5.2.4.&nbsp;&nbsp;&nbsp;<a href="#relative-dot-segments">Remove Dot Segments</a></li></ul></li><li class="tocline1">5.3.&nbsp;&nbsp;&nbsp;<a href="#recomposition">Component Recomposition</a></li><li class="tocline1">5.4.&nbsp;&nbsp;&nbsp;<a href="#reference-examples">Reference Resolution Examples</a><ul class="toc"><li class="tocline1">5.4.1.&nbsp;&nbsp;&nbsp;<a href="#relative-normal">Normal Examples</a></li><li class="tocline1">5.4.2.&nbsp;&nbsp;&nbsp;<a href="#relative-abnormal">Abnormal Examples</a></li></ul></li></ul></li><li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#comparison">Normalization and Comparison</a><ul class="toc"><li class="tocline1">6.1.&nbsp;&nbsp;&nbsp;<a href="#equivalence">Equivalence</a></li><li class="tocline1">6.2.&nbsp;&nbsp;&nbsp;<a href="#comparison-ladder">Comparison Ladder</a><ul class="toc"><li class="tocline1">6.2.1.&nbsp;&nbsp;&nbsp;<a href="#comparison-string">Simple String Comparison</a></li><li class="tocline1">6.2.2.&nbsp;&nbsp;&nbsp;<a href="#normalize-syntax">Syntax-Based Normalization</a><ul class="toc"><li class="tocline1">6.2.2.1.&nbsp;&nbsp;&nbsp;<a href="#normalize-case">Case Normalization</a></li><li class="tocline1">6.2.2.2.&nbsp;&nbsp;&nbsp;<a href="#normalize-encoding">Percent-Encoding Normalization</a></li><li class="tocline1">6.2.2.3.&nbsp;&nbsp;&nbsp;<a href="#normalize-path">Path Segment Normalization</a></li></ul></li><li class="tocline1">6.2.3.&nbsp;&nbsp;&nbsp;<a href="#normalize-scheme">Scheme-Based Normalization</a></li><li class="tocline1">6.2.4.&nbsp;&nbsp;&nbsp;<a href="#normalize-protocol">Protocol-Based Normalization</a></li></ul></li></ul></li><li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#security">Security Considerations</a><ul class="toc"><li class="tocline1">7.1.&nbsp;&nbsp;&nbsp;<a href="#security-reliability">Reliability and Consistency</a></li><li class="tocline1">7.2.&nbsp;&nbsp;&nbsp;<a href="#security-malicious">Malicious Construction</a></li><li class="tocline1">7.3.&nbsp;&nbsp;&nbsp;<a href="#security-transcoding">Back-End Transcoding</a></li><li class="tocline1">7.4.&nbsp;&nbsp;&nbsp;<a href="#security-ipv4">Rare IP Address Formats</a></li><li class="tocline1">7.5.&nbsp;&nbsp;&nbsp;<a href="#security-sensitive">Sensitive Information</a></li><li class="tocline1">7.6.&nbsp;&nbsp;&nbsp;<a href="#security-semantic">Semantic Attacks</a></li></ul></li><li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#IANA">IANA Considerations</a></li><li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgements</a></li><li class="tocline0">10.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc"><li class="tocline1">10.1.&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li><li class="tocline1">10.2.&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li></ul></li><li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#collected-abnf">Collected ABNF for URI</a></li><li class="tocline0">B.&nbsp;&nbsp;&nbsp;<a href="#regexp">Parsing a URI Reference with a Regular Expression</a></li><li class="tocline0">C.&nbsp;&nbsp;&nbsp;<a href="#delimiting">Delimiting a URI in Context</a></li><li class="tocline0">D.&nbsp;&nbsp;&nbsp;<a href="#changes">Changes from RFC 2396</a><ul class="toc"><li class="tocline1">D.1.&nbsp;&nbsp;&nbsp;<a href="#additions">Additions</a></li><li class="tocline1">D.2.&nbsp;&nbsp;&nbsp;<a href="#modifications">Modifications</a></li></ul></li><li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li><li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li><li class="tocline0"><a href="#rfc.index">Index</a></li></ul><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a name="intro" href="#intro">Introduction</a></h1><p id="rfc.section.1.p.1">A
 Uniform Resource Identifier (URI) provides a simple and extensible 
means for identifying a resource. This specification of URI syntax and 
semantics is derived from concepts introduced by the World Wide Web 
global information initiative, whose use of these identifiers dates from
 1990 and is described in "Universal Resource Identifiers in WWW" <a href="#RFC1630" title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</a>. The syntax is designed to meet the recommendations laid out in "Functional Recommendations for Internet Resource Locators" <a href="#RFC1736" title="Functional Recommendations for Internet Resource Locators">[RFC1736]</a> and "Functional Requirements for Uniform Resource Names" <a href="#RFC1737" title="Functional Requirements for Uniform Resource Names">[RFC1737]</a>.</p><p id="rfc.section.1.p.2">This document obsoletes <a href="#RFC2396" title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</a>, which merged "Uniform Resource Locators" <a href="#RFC1738" title="Uniform Resource Locators (URL)">[RFC1738]</a> and "Relative Uniform Resource Locators" <a href="#RFC1808" title="Relative Uniform Resource Locators">[RFC1808]</a> in order to define a single, generic syntax for all URIs. It obsoletes <a href="#RFC2732" title="Format for Literal IPv6 Addresses in URL's">[RFC2732]</a>,
 which introduced syntax for an IPv6 address. It excludes portions of 
RFC 1738 that defined the specific syntax of individual URI schemes; 
those portions will be updated as separate documents. The process for 
registration of new URI schemes is defined separately by <a href="#BCP35" title="Registration Procedures for URL Scheme Names">[BCP35]</a>. Advice for designers of new URI schemes can be found in <a href="#RFC2718" title="Guidelines for new URL Schemes">[RFC2718]</a>. All significant changes from RFC 2396 are noted in <a href="#changes" title="Changes from RFC 2396">Appendix&nbsp;D</a>.</p><div id="rfc.iref.1"></div><div id="rfc.iref.2"></div><div id="rfc.iref.3"></div><p id="rfc.section.1.p.3">This specification uses the terms "character" and "coded character set" in accordance with the definitions provided in <a href="#BCP19" title="IANA Charset Registration Procedures">[BCP19]</a>, and "character encoding" in place of what <a href="#BCP19" title="IANA Charset Registration Procedures">[BCP19]</a> refers to as a "charset".</p><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a>&nbsp;<a name="overview" href="#overview">Overview of URIs</a></h2><p id="rfc.section.1.1.p.1">URIs are characterized as follows:</p><div id="rfc.iref.4"></div><p id="rfc.section.1.1.p.2">Uniform </p><dl><dd style="margin-top: .5em">Uniformity
 provides several benefits. It allows different types of resource 
identifiers to be used in the same context, even when the mechanisms 
used to access those resources may differ. It allows uniform semantic 
interpretation of common syntactic conventions across different types of
 resource identifiers. It allows introduction of new types of resource 
identifiers without interfering with the way that existing identifiers 
are used. It allows the identifiers to be reused in many different 
contexts, thus permitting new applications or protocols to leverage a 
pre-existing, large, and widely used set of resource identifiers.</dd></dl><div id="rfc.iref.5"></div><p id="rfc.section.1.1.p.3">Resource </p><dl><dd style="margin-top: .5em">This
 specification does not limit the scope of what might be a resource; 
rather, the term "resource" is used in a general sense for whatever 
might be identified by a URI. Familiar examples include an electronic 
document, an image, a source of information with a consistent purpose 
(e.g., "today's weather report for Los Angeles"), a service (e.g., an 
HTTP-to-SMS gateway), and a collection of other resources. A resource is
 not necessarily accessible via the Internet; e.g., human beings, 
corporations, and bound books in a library can also be resources. 
Likewise, abstract concepts can be resources, such as the operators and 
operands of a mathematical equation, the types of a relationship (e.g., 
"parent" or "employee"), or numeric values (e.g., zero, one, and 
infinity).</dd></dl><div id="rfc.iref.6"></div><p id="rfc.section.1.1.p.4">Identifier </p><dl><dd style="margin-top: .5em">An
 identifier embodies the information required to distinguish what is 
being identified from all other things within its scope of 
identification. Our use of the terms "identify" and "identifying" refer 
to this purpose of distinguishing one resource from all other resources,
 regardless of how that purpose is accomplished (e.g., by name, address,
 or context). These terms should not be mistaken as an assumption that 
an identifier defines or embodies the identity of what is referenced, 
though that may be the case for some identifiers. Nor should it be 
assumed that a system using URIs will access the resource identified: in
 many cases, URIs are used to denote resources without any intention 
that they be accessed. Likewise, the "one" resource identified might not
 be singular in nature (e.g., a resource might be a named set or a 
mapping that varies over time).</dd></dl><p id="rfc.section.1.1.p.5">A URI is an identifier consisting of a sequence of characters matching the syntax rule named &lt;URI&gt; in <a href="#components" title="Syntax Components">Section&nbsp;3</a>. It enables uniform identification of resources via a separately defined extensible set of naming schemes (<a href="#scheme" title="Scheme">Section&nbsp;3.1</a>). How that identification is accomplished, assigned, or enabled is delegated to each scheme specification.</p><p id="rfc.section.1.1.p.6">This
 specification does not place any limits on the nature of a resource, 
the reasons why an application might seek to refer to a resource, or the
 kinds of systems that might use URIs for the sake of identifying 
resources. This specification does not require that a URI persists in 
identifying the same resource over time, though that is a common goal of
 all URI schemes. Nevertheless, nothing in this specification prevents 
an application from limiting itself to particular types of resources, or
 to a subset of URIs that maintains characteristics desired by that 
application.</p><p id="rfc.section.1.1.p.7">URIs have a global scope and
 are interpreted consistently regardless of context, though the result 
of that interpretation may be in relation to the end-user's context. For
 example, "http://localhost/" has the same interpretation for every user
 of that reference, even though the network interface corresponding to 
"localhost" may be different for each end-user: interpretation is 
independent of access. However, an action made on the basis of that 
reference will take place in relation to the end-user's context, which 
implies that an action intended to refer to a globally unique thing must
 use a URI that distinguishes that resource from all other things. URIs 
that identify in relation to the end-user's local context should only be
 used when the context itself is a defining aspect of the resource, such
 as when an on-line help manual refers to a file on the end-user's file 
system (e.g., "file:///etc/hosts").</p><div id="rfc.iref.7"></div><h3 id="rfc.section.1.1.1"><a href="#rfc.section.1.1.1">1.1.1.</a>&nbsp;<a name="generic-syntax" href="#generic-syntax">Generic Syntax</a></h3><p id="rfc.section.1.1.1.p.1">Each URI begins with a scheme name, as defined in <a href="#scheme" title="Scheme">Section&nbsp;3.1</a>,
 that refers to a specification for assigning identifiers within that 
scheme. As such, the URI syntax is a federated and extensible naming 
system wherein each scheme's specification may further restrict the 
syntax and semantics of identifiers using that scheme.</p><p id="rfc.section.1.1.1.p.2">This
 specification defines those elements of the URI syntax that are 
required of all URI schemes or are common to many URI schemes. It thus 
defines the syntax and semantics needed to implement a 
scheme-independent parsing mechanism for URI references, by which the 
scheme-dependent handling of a URI can be postponed until the 
scheme-dependent semantics are needed. Likewise, protocols and data 
formats that make use of URI references can refer to this specification 
as a definition for the range of syntax allowed for all URIs, including 
those schemes that have yet to be defined. This decouples the evolution 
of identification schemes from the evolution of protocols, data formats,
 and implementations that make use of URIs.</p><p id="rfc.section.1.1.1.p.3">A
 parser of the generic URI syntax can parse any URI reference into its 
major components. Once the scheme is determined, further scheme-specific
 parsing can be performed on the components. In other words, the URI 
generic syntax is a superset of the syntax of all URI schemes.</p><h3 id="rfc.section.1.1.2"><a href="#rfc.section.1.1.2">1.1.2.</a>&nbsp;<a name="examples" href="#examples">Examples</a></h3><div id="rfc.figure.u.1"></div><p>The following example URIs illustrate several URI schemes and variations in their common syntax components:</p><pre>   ftp://ftp.is.co.za/rfc/rfc1808.txt

   http://www.ietf.org/rfc/rfc2396.txt

   ldap://[2001:db8::7]/c=GB?objectClass?one

   mailto:John.Doe@example.com

   news:comp.infosystems.www.servers.unix

   tel:<span class="skype_pnh_print_container">+1-816-555-1212</span><span tabindex="-1" dir="ltr" class="skype_pnh_container"><span class="skype_pnh_mark"> begin_of_the_skype_highlighting</span>&nbsp;<span dir="ltr" title="Chiama questo numero in Stati Uniti d'America con Skype: +18165551212" class="skype_pnh_highlighting_inactive_common"><span skypeaction="skype_dropdown" class="skype_pnh_left_span">&nbsp;&nbsp;</span><span skypeaction="skype_dropdown" title="Opzioni Skype " class="skype_pnh_dropart_span"><span skypeaction="skype_dropdown" style="background-position:-5849px 1px !important;" class="skype_pnh_dropart_flag_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>&nbsp;&nbsp;&nbsp;</span><span class="skype_pnh_textarea_span"><span class="skype_pnh_text_span">+1-816-555-1212</span></span><span class="skype_pnh_right_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>&nbsp;<span class="skype_pnh_mark">end_of_the_skype_highlighting</span></span>

   telnet://192.0.2.16:80/

   urn:oasis:names:specification:docbook:dtd:xml:4.1.2
</pre><div id="rfc.iref.8"></div><div id="rfc.iref.9"></div><div id="rfc.iref.10"></div><div id="rfc.iref.11"></div><h3 id="rfc.section.1.1.3"><a href="#rfc.section.1.1.3">1.1.3.</a>&nbsp;<a name="URLvsURN" href="#URLvsURN">URI, URL, and URN</a></h3><p id="rfc.section.1.1.3.p.1">A
 URI can be further classified as a locator, a name, or both. The term 
"Uniform Resource Locator" (URL) refers to the subset of URIs that, in 
addition to identifying a resource, provide a means of locating the 
resource by describing its primary access mechanism (e.g., its network 
"location"). The term "Uniform Resource Name" (URN) has been used 
historically to refer to both URIs under the "urn" scheme <a href="#RFC2141" title="URN Syntax">[RFC2141]</a>,
 which are required to remain globally unique and persistent even when 
the resource ceases to exist or becomes unavailable, and to any other 
URI with the properties of a name.</p><p id="rfc.section.1.1.3.p.2">An 
individual scheme does not have to be classified as being just one of 
"name" or "locator". Instances of URIs from any given scheme may have 
the characteristics of names or locators or both, often depending on the
 persistence and care in the assignment of identifiers by the naming 
authority, rather than on any quality of the scheme. Future 
specifications and related documentation should use the general term 
"URI" rather than the more restrictive terms "URL" and "URN" <a href="#RFC3305" title="Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations">[RFC3305]</a>.</p><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2.</a>&nbsp;<a name="design" href="#design">Design Considerations</a></h2><div id="rfc.iref.12"></div><h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1.</a>&nbsp;<a name="transcription" href="#transcription">Transcription</a></h3><p id="rfc.section.1.2.1.p.1">The
 URI syntax has been designed with global transcription as one of its 
main considerations. A URI is a sequence of characters from a very 
limited set: the letters of the basic Latin alphabet, digits, and a few 
special characters. A URI may be represented in a variety of ways; e.g.,
 ink on paper, pixels on a screen, or a sequence of character encoding 
octets. The interpretation of a URI depends only on the characters used 
and not on how those characters are represented in a network protocol.</p><p id="rfc.section.1.2.1.p.2">The
 goal of transcription can be described by a simple scenario. Imagine 
two colleagues, Sam and Kim, sitting in a pub at an international 
conference and exchanging research ideas. Sam asks Kim for a location to
 get more information, so Kim writes the URI for the research site on a 
napkin. Upon returning home, Sam takes out the napkin and types the URI 
into a computer, which then retrieves the information to which Kim 
referred.</p><p id="rfc.section.1.2.1.p.3">There are several design considerations revealed by the scenario: </p><ul><li>A URI is a sequence of characters that is not always represented as a sequence of octets.</li><li>A
 URI might be transcribed from a non-network source and thus should 
consist of characters that are most likely able to be entered into a 
computer, within the constraints imposed by keyboards (and related input
 devices) across languages and locales.</li><li>A URI often has to be 
remembered by people, and it is easier for people to remember a URI when
 it consists of meaningful or familiar components.</li></ul><p id="rfc.section.1.2.1.p.4">These
 design considerations are not always in alignment. For example, it is 
often the case that the most meaningful name for a URI component would 
require characters that cannot be typed into some systems. The ability 
to transcribe a resource identifier from one medium to another has been 
considered more important than having a URI consist of the most 
meaningful of components.</p><p id="rfc.section.1.2.1.p.5">In local or 
regional contexts and with improving technology, users might benefit 
from being able to use a wider range of characters; such use is not 
defined by this specification. Percent-encoded octets (<a href="#percent-encoding" title="Percent-Encoding">Section&nbsp;2.1</a>)
 may be used within a URI to represent characters outside the range of 
the US-ASCII coded character set if this representation is allowed by 
the scheme or by the protocol element in which the URI is referenced. 
Such a definition should specify the character encoding used to map 
those characters to octets prior to being percent-encoded for the URI.</p><div id="rfc.iref.13"></div><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2.</a>&nbsp;<a name="identification" href="#identification">Separating Identification from Interaction</a></h3><p id="rfc.section.1.2.2.p.1">A
 common misunderstanding of URIs is that they are only used to refer to 
accessible resources. The URI itself only provides identification; 
access to the resource is neither guaranteed nor implied by the presence
 of a URI. Instead, any operation associated with a URI reference is 
defined by the protocol element, data format attribute, or natural 
language text in which it appears.</p><div id="rfc.iref.14"></div><div id="rfc.iref.15"></div><p id="rfc.section.1.2.2.p.2">Given
 a URI, a system may attempt to perform a variety of operations on the 
resource, as might be characterized by words such as "access", "update",
 "replace", or "find attributes". Such operations are defined by the 
protocols that make use of URIs, not by this specification. However, we 
do use a few general terms for describing common operations on URIs. URI
 "resolution" is the process of determining an access mechanism and the 
appropriate parameters necessary to dereference a URI; this resolution 
may require several iterations. To use that access mechanism to perform 
an action on the URI's resource is to "dereference" the URI.</p><div id="rfc.iref.16"></div><div id="rfc.iref.17"></div><p id="rfc.section.1.2.2.p.3">When
 URIs are used within information retrieval systems to identify sources 
of information, the most common form of URI dereference is "retrieval": 
making use of a URI in order to retrieve a representation of its 
associated resource. A "representation" is a sequence of octets, along 
with representation metadata describing those octets, that constitutes a
 record of the state of the resource at the time when the representation
 is generated. Retrieval is achieved by a process that might include 
using the URI as a cache key to check for a locally cached 
representation, resolution of the URI to determine an appropriate access
 mechanism (if any), and dereference of the URI for the sake of applying
 a retrieval operation. Depending on the protocols used to perform the 
retrieval, additional information might be supplied about the resource 
(resource metadata) and its relation to other resources.</p><div id="rfc.iref.18"></div><p id="rfc.section.1.2.2.p.4">URI
 references in information retrieval systems are designed to be 
late-binding: the result of an access is generally determined when it is
 accessed and may vary over time or due to other aspects of the 
interaction. These references are created in order to be used in the 
future: what is being identified is not some specific result that was 
obtained in the past, but rather some characteristic that is expected to
 be true for future results. In such cases, the resource referred to by 
the URI is actually a sameness of characteristics as observed over time,
 perhaps elucidated by additional comments or assertions made by the 
resource provider.</p><p id="rfc.section.1.2.2.p.5">Although many URI 
schemes are named after protocols, this does not imply that use of these
 URIs will result in access to the resource via the named protocol. URIs
 are often used simply for the sake of identification. Even when a URI 
is used to retrieve a representation of a resource, that access might be
 through gateways, proxies, caches, and name resolution services that 
are independent of the protocol associated with the scheme name. The 
resolution of some URIs may require the use of more than one protocol 
(e.g., both DNS and HTTP are typically used to access an "http" URI's 
origin server when a representation isn't found in a local cache).</p><div id="rfc.iref.19"></div><h3 id="rfc.section.1.2.3"><a href="#rfc.section.1.2.3">1.2.3.</a>&nbsp;<a name="hierarchical" href="#hierarchical">Hierarchical Identifiers</a></h3><p id="rfc.section.1.2.3.p.1">The
 URI syntax is organized hierarchically, with components listed in order
 of decreasing significance from left to right. For some URI schemes, 
the visible hierarchy is limited to the scheme itself: everything after 
the scheme component delimiter (":") is considered opaque to URI 
processing. Other URI schemes make the hierarchy explicit and visible to
 generic parsing algorithms.</p><p id="rfc.section.1.2.3.p.2">The 
generic syntax uses the slash ("/"), question mark ("?"), and number 
sign ("#") characters to delimit components that are significant to the 
generic parser's hierarchical interpretation of an identifier. In 
addition to aiding the readability of such identifiers through the 
consistent use of familiar syntax, this uniform representation of 
hierarchy across naming schemes allows scheme-independent references to 
be made relative to that hierarchy.</p><div id="rfc.iref.20"></div><p id="rfc.section.1.2.3.p.3">It
 is often the case that a group or "tree" of documents has been 
constructed to serve a common purpose, wherein the vast majority of URI 
references in these documents point to resources within the tree rather 
than outside it. Similarly, documents located at a particular site are 
much more likely to refer to other resources at that site than to 
resources at remote sites. Relative referencing of URIs allows document 
trees to be partially independent of their location and access scheme. 
For instance, it is possible for a single set of hypertext documents to 
be simultaneously accessible and traversable via each of the "file", 
"http", and "ftp" schemes if the documents refer to each other with 
relative references. Furthermore, such document trees can be moved, as a
 whole, without changing any of the relative references.</p><p id="rfc.section.1.2.3.p.4">A relative reference (<a href="#relative-ref" title="Relative Reference">Section&nbsp;4.2</a>)
 refers to a resource by describing the difference within a hierarchical
 name space between the reference context and the target URI. The 
reference resolution algorithm, presented in <a href="#reference-resolution" title="Reference Resolution">Section&nbsp;5</a>,
 defines how such a reference is transformed to the target URI. As 
relative references can only be used within the context of a 
hierarchical URI, designers of new URI schemes should use a syntax 
consistent with the generic syntax's hierarchical components unless 
there are compelling reasons to forbid relative referencing within that 
scheme. </p><dl><dd style="margin-top: .5em">NOTE: Previous 
specifications used the terms "partial URI" and "relative URI" to denote
 a relative reference to a URI. As some readers misunderstood those 
terms to mean that relative URIs are a subset of URIs rather than a 
method of referencing URIs, this specification simply refers to them as 
relative references.</dd></dl><p id="rfc.section.1.2.3.p.5">All URI 
references are parsed by generic syntax parsers when used. However, 
because hierarchical processing has no effect on an absolute URI used in
 a reference unless it contains one or more dot-segments (complete path 
segments of "." or "..", as described in <a href="#path" title="Path">Section&nbsp;3.3</a>),
 URI scheme specifications can define opaque identifiers by disallowing 
use of slash characters, question mark characters, and the URIs 
"scheme:." and "scheme:..".</p><div id="rfc.iref.21"></div><div id="rfc.iref.22"></div><div id="rfc.iref.23"></div><div id="rfc.iref.24"></div><div id="rfc.iref.25"></div><div id="rfc.iref.26"></div><div id="rfc.iref.27"></div><div id="rfc.iref.28"></div><div id="rfc.iref.29"></div><h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3.</a>&nbsp;<a name="notation" href="#notation">Syntax Notation</a></h2><p id="rfc.section.1.3.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC2234" title="Augmented BNF for Syntax Specifications: ABNF">[RFC2234]</a>,
 including the following core ABNF syntax rules defined by that 
specification: ALPHA (letters), CR (carriage return), DIGIT (decimal 
digits), DQUOTE (double quote), HEXDIG (hexadecimal digits), LF (line 
feed), and SP (space). The complete URI syntax is collected in <a href="#collected-abnf" title="Collected ABNF for URI">Appendix&nbsp;A</a>.</p><div id="rfc.iref.30"></div><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a name="characters" href="#characters">Characters</a></h1><p id="rfc.section.2.p.1">The
 URI syntax provides a method of encoding data, presumably for the sake 
of identifying a resource, as a sequence of characters. The URI 
characters are, in turn, frequently encoded as octets for transport or 
presentation. This specification does not mandate any particular 
character encoding for mapping between URI characters and the octets 
used to store or transmit those characters. When a URI appears in a 
protocol element, the character encoding is defined by that protocol; 
without such a definition, a URI is assumed to be in the same character 
encoding as the surrounding text.</p><p id="rfc.section.2.p.2">The ABNF 
notation defines its terminal values to be non-negative integers 
(codepoints) based on the US-ASCII coded character set <a href="#ASCII" title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[ASCII]</a>.
 Because a URI is a sequence of characters, we must invert that relation
 in order to understand the URI syntax. Therefore, the integer values 
used by the ABNF must be mapped back to their corresponding characters 
via US-ASCII in order to complete the syntax rules.</p><p id="rfc.section.2.p.3">A
 URI is composed from a limited set of characters consisting of digits, 
letters, and a few graphic symbols. A reserved subset of those 
characters may be used to delimit syntax components within a URI while 
the remaining characters, including both the unreserved set and those 
reserved characters not acting as delimiters, define each component's 
identifying data.</p><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a>&nbsp;<a name="percent-encoding" href="#percent-encoding">Percent-Encoding</a></h2><div id="rfc.figure.u.2"></div><p> <a name="rfc.iref.31"></a>  <a name="rfc.iref.32"></a>
 A percent-encoding mechanism is used to represent a data octet in a 
component when that octet's corresponding character is outside the 
allowed set or is being used as a delimiter of, or within, the 
component. A percent-encoded octet is encoded as a character triplet, 
consisting of the percent character "%" followed by the two hexadecimal 
digits representing that octet's numeric value. For example, "%20" is 
the percent-encoding for the binary octet "00100000" (ABNF: %x20), which
 in US-ASCII corresponds to the space character (SP). <a href="#when-to-percent-encode" title="When to Encode or Decode">Section&nbsp;2.4</a> describes when percent-encoding and decoding is applied. <a name="rfc.iref.33"></a> </p><pre>   pct-encoded = "%" HEXDIG HEXDIG
</pre><p>The uppercase hexadecimal digits 'A' through 'F' are equivalent
 to the lowercase digits 'a' through 'f', respectively. If two URIs 
differ only in the case of hexadecimal digits used in percent-encoded 
octets, they are equivalent. For consistency, URI producers and 
normalizers should use uppercase hexadecimal digits for all 
percent-encodings.</p><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2.</a>&nbsp;<a name="reserved" href="#reserved">Reserved Characters</a></h2><div id="rfc.figure.u.3"></div><p> <a name="rfc.iref.34"></a>
 URIs include components and subcomponents that are delimited by 
characters in the "reserved" set. These characters are called "reserved"
 because they may (or may not) be defined as delimiters by the generic 
syntax, by each scheme-specific syntax, or by the 
implementation-specific syntax of a URI's dereferencing algorithm. If 
data for a URI component would conflict with a reserved character's 
purpose as a delimiter, then the conflicting data must be 
percent-encoded before the URI is formed. <a name="rfc.iref.35"></a>  <a name="rfc.iref.36"></a>  <a name="rfc.iref.37"></a>  <a name="rfc.iref.38"></a>  <a name="rfc.iref.39"></a> </p><pre>   reserved    = gen-delims / sub-delims

   gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

   sub-delims  = "!" / "$" / "&amp;" / "'" / "(" / ")"
               / "*" / "+" / "," / ";" / "="
</pre><p id="rfc.section.2.2.p.2">The purpose of reserved characters is 
to provide a set of delimiting characters that are distinguishable from 
other data within a URI. URIs that differ in the replacement of a 
reserved character with its corresponding percent-encoded octet are not 
equivalent. Percent-encoding a reserved character, or decoding a 
percent-encoded octet that corresponds to a reserved character, will 
change how the URI is interpreted by most applications. Thus, characters
 in the reserved set are protected from normalization and are therefore 
safe to be used by scheme-specific and producer-specific algorithms for 
delimiting data subcomponents within a URI.</p><p id="rfc.section.2.2.p.3">A subset of the reserved characters (gen-delims) is used as delimiters of the generic URI components described in <a href="#components" title="Syntax Components">Section&nbsp;3</a>.
 A component's ABNF syntax rule will not use the reserved or gen-delims 
rule names directly; instead, each syntax rule lists the characters 
allowed within that component (i.e., not delimiting it), and any of 
those characters that are also in the reserved set are "reserved" for 
use as subcomponent delimiters within the component. Only the most 
common subcomponents are defined by this specification; other 
subcomponents may be defined by a URI scheme's specification, or by the 
implementation-specific syntax of a URI's dereferencing algorithm, 
provided that such subcomponents are delimited by characters in the 
reserved set allowed within that component.</p><p id="rfc.section.2.2.p.4">URI
 producing applications should percent-encode data octets that 
correspond to characters in the reserved set unless these characters are
 specifically allowed by the URI scheme to represent data in that 
component. If a reserved character is found in a URI component and no 
delimiting role is known for that character, then it must be interpreted
 as representing the data octet corresponding to that character's 
encoding in US-ASCII.</p><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3.</a>&nbsp;<a name="unreserved" href="#unreserved">Unreserved Characters</a></h2><div id="rfc.figure.u.4"></div><p> <a name="rfc.iref.40"></a>
 Characters that are allowed in a URI but do not have a reserved purpose
 are called unreserved. These include uppercase and lowercase letters, 
decimal digits, hyphen, period, underscore, and tilde. <a name="rfc.iref.41"></a> </p><pre>   unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
</pre><p id="rfc.section.2.3.p.2">URIs that differ in the replacement of
 an unreserved character with its corresponding percent-encoded US-ASCII
 octet are equivalent: they identify the same resource. However, URI 
comparison implementations do not always perform normalization prior to 
comparison (see <a href="#comparison" title="Normalization and Comparison">Section&nbsp;6</a>).
 For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A
 and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore 
(%5F), or tilde (%7E) should not be created by URI producers and, when 
found in a URI, should be decoded to their corresponding unreserved 
characters by URI normalizers.</p><h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4.</a>&nbsp;<a name="when-to-percent-encode" href="#when-to-percent-encode">When to Encode or Decode</a></h2><p id="rfc.section.2.4.p.1">Under
 normal circumstances, the only time when octets within a URI are 
percent-encoded is during the process of producing the URI from its 
component parts. This is when an implementation determines which of the 
reserved characters are to be used as subcomponent delimiters and which 
can be safely used as data. Once produced, a URI is always in its 
percent-encoded form.</p><p id="rfc.section.2.4.p.2">When a URI is 
dereferenced, the components and subcomponents significant to the 
scheme-specific dereferencing process (if any) must be parsed and 
separated before the percent-encoded octets within those components can 
be safely decoded, as otherwise the data may be mistaken for component 
delimiters. The only exception is for percent-encoded octets 
corresponding to characters in the unreserved set, which can be decoded 
at any time. For example, the octet corresponding to the tilde ("~") 
character is often encoded as "%7E" by older URI processing 
implementations; the "%7E" can be replaced by "~" without changing its 
interpretation.</p><p id="rfc.section.2.4.p.3">Because the percent ("%")
 character serves as the indicator for percent-encoded octets, it must 
be percent-encoded as "%25" for that octet to be used as data within a 
URI. Implementations must not percent-encode or decode the same string 
more than once, as decoding an already decoded string might lead to 
misinterpreting a percent data octet as the beginning of a 
percent-encoding, or vice versa in the case of percent-encoding an 
already percent-encoded string.</p><h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5.</a>&nbsp;<a name="identifying-data" href="#identifying-data">Identifying Data</a></h2><p id="rfc.section.2.5.p.1">URI
 characters provide identifying data for each of the URI components, 
serving as an external interface for identification between systems. 
Although the presence and nature of the URI production interface is 
hidden from clients that use its URIs (and is thus beyond the scope of 
the interoperability requirements defined by this specification), it is a
 frequent source of confusion and errors in the interpretation of URI 
character issues. Implementers have to be aware that there are multiple 
character encodings involved in the production and transmission of URIs:
 local name and data encoding, public interface encoding, URI character 
encoding, data format encoding, and protocol encoding.</p><p id="rfc.section.2.5.p.2">Local
 names, such as file system names, are stored with a local character 
encoding. URI producing applications (e.g., origin servers) will 
typically use the local encoding as the basis for producing meaningful 
names. The URI producer will transform the local encoding to one that is
 suitable for a public interface and then transform the public interface
 encoding into the restricted set of URI characters (reserved, 
unreserved, and percent-encodings). Those characters are, in turn, 
encoded as octets to be used as a reference within a data format (e.g., a
 document charset), and such data formats are often subsequently encoded
 for transmission over Internet protocols.</p><p id="rfc.section.2.5.p.3">For
 most systems, an unreserved character appearing within a URI component 
is interpreted as representing the data octet corresponding to that 
character's encoding in US-ASCII. Consumers of URIs assume that the 
letter "X" corresponds to the octet "01011000", and even when that 
assumption is incorrect, there is no harm in making it. A system that 
internally provides identifiers in the form of a different character 
encoding, such as EBCDIC, will generally perform character translation 
of textual identifiers to UTF-8 <a href="#STD63" title="UTF-8, a transformation format of ISO 10646">[STD63]</a>
 (or some other superset of the US-ASCII character encoding) at an 
internal interface, thereby providing more meaningful identifiers than 
those resulting from simply percent-encoding the original octets.</p><p id="rfc.section.2.5.p.4">For
 example, consider an information service that provides data, stored 
locally using an EBCDIC-based file system, to clients on the Internet 
through an HTTP server. When an author creates a file with the name 
"Laguna Beach" on that file system, the "http" URI corresponding to that
 resource is expected to contain the meaningful string "Laguna%20Beach".
 If, however, that server produces URIs by using an overly simplistic 
raw octet mapping, then the result would be a URI containing 
"%D3%81%87%A4%95%81@%C2%85%81%83%88". An internal transcoding interface 
fixes this problem by transcoding the local name to a superset of 
US-ASCII prior to producing the URI. Naturally, proper interpretation of
 an incoming URI on such an interface requires that percent-encoded 
octets be decoded (e.g., "%20" to SP) before the reverse transcoding is 
applied to obtain the local name.</p><p id="rfc.section.2.5.p.5">In some
 cases, the internal interface between a URI component and the 
identifying data that it has been crafted to represent is much less 
direct than a character encoding translation. For example, portions of a
 URI might reflect a query on non-ASCII data, or numeric coordinates on a
 map. Likewise, a URI scheme may define components with additional 
encoding requirements that are applied prior to forming the component 
and producing the URI.</p><p id="rfc.section.2.5.p.6">When a new URI 
scheme defines a component that represents textual data consisting of 
characters from the Universal Character Set <a href="#UCS" title="Information Technology - Universal Multiple-Octet Coded Character Set (UCS)">[UCS]</a>, the data should first be encoded as octets according to the UTF-8 character encoding <a href="#STD63" title="UTF-8, a transformation format of ISO 10646">[STD63]</a>;
 then only those octets that do not correspond to characters in the 
unreserved set should be percent-encoded. For example, the character A 
would be represented as "A", the character LATIN CAPITAL LETTER A WITH 
GRAVE would be represented as "%C3%80", and the character KATAKANA 
LETTER A would be represented as "%E3%82%A2".</p><div id="rfc.iref.42"></div><div id="rfc.iref.43"></div><div id="rfc.iref.44"></div><div id="rfc.iref.45"></div><div id="rfc.iref.46"></div><div id="rfc.iref.47"></div><div id="rfc.iref.48"></div><div id="rfc.iref.49"></div><div id="rfc.iref.50"></div><div id="rfc.iref.51"></div><div id="rfc.iref.52"></div><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a name="components" href="#components">Syntax Components</a></h1><div id="rfc.figure.u.5"></div><p>The
 generic URI syntax consists of a hierarchical sequence of components 
referred to as the scheme, authority, path, query, and fragment. <a name="rfc.iref.53"></a>  <a name="rfc.iref.54"></a>  <a name="rfc.iref.55"></a>  <a name="rfc.iref.56"></a>  <a name="rfc.iref.57"></a>  <a name="rfc.iref.58"></a>  <a name="rfc.iref.59"></a>  <a name="rfc.iref.60"></a>  <a name="rfc.iref.61"></a>  <a name="rfc.iref.62"></a> </p><pre>   URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part   = "//" authority path-abempty
               / path-absolute
               / path-rootless
               / path-empty
</pre><p>The scheme and path components are required, though the path 
may be empty (no characters). When authority is present, the path must 
either be empty or begin with a slash ("/") character. When authority is
 not present, the path cannot begin with two slash characters ("//"). 
These restrictions result in five different ABNF rules for a path (<a href="#path" title="Path">Section&nbsp;3.3</a>), only one of which will match any given URI reference.</p><div id="rfc.figure.u.6"></div><p>The following are two example URIs and their component parts:</p><pre>      foo://example.com:8042/over/there?name=ferret#nose
      \_/   \______________/\_________/ \_________/ \__/
       |           |            |            |        |
    scheme     authority       path        query   fragment
       |   _____________________|__
      / \ /                        \
      urn:example:animal:ferret:nose
</pre><div id="rfc.iref.63"></div><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1.</a>&nbsp;<a name="scheme" href="#scheme">Scheme</a></h2><p id="rfc.section.3.1.p.1">Each
 URI begins with a scheme name that refers to a specification for 
assigning identifiers within that scheme. As such, the URI syntax is a 
federated and extensible naming system wherein each scheme's 
specification may further restrict the syntax and semantics of 
identifiers using that scheme.</p><div id="rfc.figure.u.7"></div><p>Scheme
 names consist of a sequence of characters beginning with a letter and 
followed by any combination of letters, digits, plus ("+"), period 
("."), or hyphen ("-"). Although schemes are case-insensitive, the 
canonical form is lowercase and documents that specify schemes must do 
so with lowercase letters. An implementation should accept uppercase 
letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" 
as well as "http") for the sake of robustness but should only produce 
lowercase scheme names for consistency. <a name="rfc.iref.64"></a> </p><pre>   scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
</pre><p>Individual schemes are not specified by this document. The process for registration of new URI schemes is defined separately by <a href="#BCP35" title="Registration Procedures for URL Scheme Names">[BCP35]</a>.
 The scheme registry maintains the mapping between scheme names and 
their specifications. Advice for designers of new URI schemes can be 
found in <a href="#RFC2718" title="Guidelines for new URL Schemes">[RFC2718]</a>.
 URI scheme specifications must define their own syntax so that all 
strings matching their scheme-specific syntax will also match the 
&lt;absolute-URI&gt; grammar, as described in <a href="#absolute-uri" title="Absolute URI">Section&nbsp;4.3</a>.</p><p id="rfc.section.3.1.p.3">When
 presented with a URI that violates one or more scheme-specific 
restrictions, the scheme-specific resolution process should flag the 
reference as an error rather than ignore the unused parts; doing so 
reduces the number of equivalent URIs and helps detect abuses of the 
generic syntax, which might indicate that the URI has been constructed 
to mislead the user (<a href="#security-semantic" title="Semantic Attacks">Section&nbsp;7.6</a>).</p><div id="rfc.iref.65"></div><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2.</a>&nbsp;<a name="authority" href="#authority">Authority</a></h2><p id="rfc.section.3.2.p.1">Many
 URI schemes include a hierarchical element for a naming authority so 
that governance of the name space defined by the remainder of the URI is
 delegated to that authority (which may, in turn, delegate it further). 
The generic syntax provides a common means for distinguishing an 
authority based on a registered name or server address, along with 
optional port and user information.</p><div id="rfc.figure.u.8"></div><p>The
 authority component is preceded by a double slash ("//") and is 
terminated by the next slash ("/"), question mark ("?"), or number sign 
("#") character, or by the end of the URI. <a name="rfc.iref.66"></a>  <a name="rfc.iref.67"></a>  <a name="rfc.iref.68"></a>  <a name="rfc.iref.69"></a> </p><pre>   authority   = [ userinfo "@" ] host [ ":" port ]
</pre><p>URI producers and normalizers should omit the ":" delimiter 
that separates host from port if the port component is empty. Some 
schemes do not allow the userinfo and/or port subcomponents.</p><p id="rfc.section.3.2.p.3">If
 a URI contains an authority component, then the path component must 
either be empty or begin with a slash ("/") character. Non-validating 
parsers (those that merely separate a URI reference into its major 
components) will often ignore the subcomponent structure of authority, 
treating it as an opaque string from the double-slash to the first 
terminating delimiter, until such time as the URI is dereferenced.</p><div id="rfc.iref.70"></div><h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1.</a>&nbsp;<a name="userinfo" href="#userinfo">User Information</a></h3><div id="rfc.figure.u.9"></div><p>The
 userinfo subcomponent may consist of a user name and, optionally, 
scheme-specific information about how to gain authorization to access 
the resource. The user information, if present, is followed by a 
commercial at-sign ("@") that delimits it from the host. <a name="rfc.iref.71"></a> </p><pre>   userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )
</pre><p></p><p id="rfc.section.3.2.1.p.2">Use of the format 
"user:password" in the userinfo field is deprecated. Applications should
 not render as clear text any data after the first colon (":") character
 found within a userinfo subcomponent unless the data after the colon is
 the empty string (indicating no password). Applications may choose to 
ignore or reject such data when it is received as part of a reference 
and should reject the storage of such data in unencrypted form. The 
passing of authentication information in clear text has proven to be a 
security risk in almost every case where it has been used.</p><p id="rfc.section.3.2.1.p.3">Applications
 that render a URI for the sake of user feedback, such as in graphical 
hypertext browsing, should render userinfo in a way that is 
distinguished from the rest of a URI, when feasible. Such rendering will
 assist the user in cases where the userinfo has been misleadingly 
crafted to look like a trusted domain name (<a href="#security-semantic" title="Semantic Attacks">Section&nbsp;7.6</a>).</p><div id="rfc.iref.72"></div><h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2.</a>&nbsp;<a name="host" href="#host">Host</a></h3><div id="rfc.figure.u.10"></div><p>The
 host subcomponent of authority is identified by an IP literal 
encapsulated within square brackets, an IPv4 address in dotted-decimal 
form, or a registered name. The host subcomponent is case-insensitive. 
The presence of a host subcomponent within a URI does not imply that the
 scheme requires access to the given host on the Internet. In many 
cases, the host syntax is used only for the sake of reusing the existing
 registration process created and deployed for DNS, thus obtaining a 
globally unique name without the cost of deploying another registry. 
However, such use comes with its own costs: domain name ownership may 
change over time for reasons not anticipated by the URI producer. In 
other cases, the data within the host component identifies a registered 
name that has nothing to do with an Internet host. We use the name 
"host" for the ABNF rule because that is its most common purpose, not 
its only purpose. <a name="rfc.iref.73"></a> </p><pre>   host        = IP-literal / IPv4address / reg-name
</pre><p>The syntax rule for host is ambiguous because it does not 
completely distinguish between an IPv4address and a reg-name. In order 
to disambiguate the syntax, we apply the "first-match-wins" algorithm: 
If host matches the rule for IPv4address, then it should be considered 
an IPv4 address literal and not a reg-name. Although host is 
case-insensitive, producers and normalizers should use lowercase for 
registered names and hexadecimal addresses for the sake of uniformity, 
while only using uppercase letters for percent-encodings.</p><div id="rfc.figure.u.11"></div><p> <a name="rfc.iref.74"></a>  <a name="rfc.iref.75"></a>  <a name="rfc.iref.76"></a>  <a name="rfc.iref.77"></a>  <a name="rfc.iref.78"></a>  <a name="rfc.iref.79"></a> A host identified by an Internet Protocol literal address, version 6 <a href="#RFC3513" title="Internet Protocol Version 6 (IPv6) Addressing Architecture">[RFC3513]</a>
 or later, is distinguished by enclosing the IP literal within square 
brackets ("[" and "]"). This is the only place where square bracket 
characters are allowed in the URI syntax. In anticipation of future, 
as-yet-undefined IP literal address formats, an implementation may use 
an optional version flag to indicate such a format explicitly rather 
than rely on heuristic determination. <a name="rfc.iref.80"></a>  <a name="rfc.iref.81"></a>  <a name="rfc.iref.82"></a> </p><pre>   IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

   IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
</pre><p>The version flag does not indicate the IP version; rather, it 
indicates future versions of the literal format. As such, 
implementations must not provide the version flag for the existing IPv4 
and IPv6 literal address forms described below. If a URI containing an 
IP-literal that starts with "v" (case-insensitive), indicating that the 
version flag is present, is dereferenced by an application that does not
 know the meaning of that version flag, then the application should 
return an appropriate error for "address mechanism not supported".</p><p id="rfc.section.3.2.2.p.3">A
 host identified by an IPv6 literal address is represented inside the 
square brackets without a preceding version flag. The ABNF provided here
 is a translation of the text definition of an IPv6 literal address 
provided in <a href="#RFC3513" title="Internet Protocol Version 6 (IPv6) Addressing Architecture">[RFC3513]</a>. This syntax does not support IPv6 scoped addressing zone identifiers.</p><div id="rfc.figure.u.12"></div><p>A
 128-bit IPv6 address is divided into eight 16-bit pieces. Each piece is
 represented numerically in case-insensitive hexadecimal, using one to 
four hexadecimal digits (leading zeroes are permitted). The eight 
encoded pieces are given most-significant first, separated by colon 
characters. Optionally, the least-significant two pieces may instead be 
represented in IPv4 address textual format. A sequence of one or more 
consecutive zero-valued 16-bit pieces within the address may be elided, 
omitting all their digits and leaving exactly two consecutive colons in 
their place to mark the elision. <a name="rfc.iref.83"></a>  <a name="rfc.iref.84"></a>  <a name="rfc.iref.85"></a> </p><pre>   IPv6address =                            6( h16 ":" ) ls32
               /                       "::" 5( h16 ":" ) ls32
               / [               h16 ] "::" 4( h16 ":" ) ls32
               / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
               / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
               / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
               / [ *4( h16 ":" ) h16 ] "::"              ls32
               / [ *5( h16 ":" ) h16 ] "::"              h16
               / [ *6( h16 ":" ) h16 ] "::"

   ls32        = ( h16 ":" h16 ) / IPv4address
               ; least-significant 32 bits of address

   h16         = 1*4HEXDIG
               ; 16 bits of address represented in hexadecimal
</pre><div id="rfc.figure.u.13"></div><p> <a name="rfc.iref.86"></a>  <a name="rfc.iref.87"></a>  <a name="rfc.iref.88"></a>
 A host identified by an IPv4 literal address is represented in 
dotted-decimal notation (a sequence of four decimal numbers in the range
 0 to 255, separated by "."), as described in <a href="#RFC1123" title="Requirements for Internet Hosts - Application and Support">[RFC1123]</a> by reference to <a href="#RFC0952" title="DoD Internet host table specification">[RFC0952]</a>. Note that other forms of dotted notation may be interpreted on some platforms, as described in <a href="#security-ipv4" title="Rare IP Address Formats">Section&nbsp;7.4</a>, but only the dotted-decimal form of four octets is allowed by this grammar. <a name="rfc.iref.89"></a>  <a name="rfc.iref.90"></a> </p><pre>   IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet

   dec-octet   = DIGIT                 ; 0-9
               / %x31-39 DIGIT         ; 10-99
               / "1" 2DIGIT            ; 100-199
               / "2" %x30-34 DIGIT     ; 200-249
               / "25" %x30-35          ; 250-255
</pre><div id="rfc.figure.u.14"></div><p> <a name="rfc.iref.91"></a>  <a name="rfc.iref.92"></a>
 A host identified by a registered name is a sequence of characters 
usually intended for lookup within a locally defined host or service 
name registry, though the URI's scheme-specific semantics may require 
that a specific registry (or fixed name table) be used instead. The most
 common name registry mechanism is the Domain Name System (DNS). A 
registered name intended for lookup in the DNS uses the syntax defined 
in Section 3.5 of <a href="#RFC1034" title="Domain names - concepts and facilities">[RFC1034]</a> and Section 2.1 of <a href="#RFC1123" title="Requirements for Internet Hosts - Application and Support">[RFC1123]</a>.
 Such a name consists of a sequence of domain labels separated by ".", 
each domain label starting and ending with an alphanumeric character and
 possibly also containing "-" characters. The rightmost domain label of a
 fully qualified domain name in DNS may be followed by a single "." and 
should be if it is necessary to distinguish between the complete domain 
name and some local domain. <a name="rfc.iref.93"></a> </p><pre>   reg-name    = *( unreserved / pct-encoded / sub-delims )
</pre><p>If the URI scheme defines a default for host, then that default
 applies when the host subcomponent is undefined or when the registered 
name is empty (zero length). For example, the "file" URI scheme is 
defined so that no authority, an empty host, and "localhost" all mean 
the end-user's machine, whereas the "http" scheme considers a missing 
authority or empty host invalid.</p><p id="rfc.section.3.2.2.p.7">This 
specification does not mandate a particular registered name lookup 
technology and therefore does not restrict the syntax of reg-name beyond
 what is necessary for interoperability. Instead, it delegates the issue
 of registered name syntax conformance to the operating system of each 
application performing URI resolution, and that operating system decides
 what it will allow for the purpose of host identification. A URI 
resolution implementation might use DNS, host tables, yellow pages, 
NetInfo, WINS, or any other system for lookup of registered names. 
However, a globally scoped naming system, such as DNS fully qualified 
domain names, is necessary for URIs intended to have global scope. URI 
producers should use names that conform to the DNS syntax, even when use
 of DNS is not immediately apparent, and should limit these names to no 
more than 255 characters in length.</p><p id="rfc.section.3.2.2.p.8">The
 reg-name syntax allows percent-encoded octets in order to represent 
non-ASCII registered names in a uniform way that is independent of the 
underlying name resolution technology. Non-ASCII characters must first 
be encoded according to UTF-8 <a href="#STD63" title="UTF-8, a transformation format of ISO 10646">[STD63]</a>,
 and then each octet of the corresponding UTF-8 sequence must be 
percent-encoded to be represented as URI characters. URI producing 
applications must not use percent-encoding in host unless it is used to 
represent a UTF-8 character sequence. When a non-ASCII registered name 
represents an internationalized domain name intended for resolution via 
the DNS, the name must be transformed to the IDNA encoding <a href="#RFC3490" title="Internationalizing Domain Names in Applications (IDNA)">[RFC3490]</a>
 prior to name lookup. URI producers should provide these registered 
names in the IDNA encoding, rather than a percent-encoding, if they wish
 to maximize interoperability with legacy URI resolvers.</p><div id="rfc.iref.94"></div><h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3.</a>&nbsp;<a name="port" href="#port">Port</a></h3><div id="rfc.figure.u.15"></div><p>The
 port subcomponent of authority is designated by an optional port number
 in decimal following the host and delimited from it by a single colon 
(":") character. <a name="rfc.iref.95"></a> </p><pre>   port        = *DIGIT
</pre><p>A scheme may define a default port. For example, the "http" 
scheme defines a default port of "80", corresponding to its reserved TCP
 port number. The type of port designated by the port number (e.g., TCP,
 UDP, SCTP) is defined by the URI scheme. URI producers and normalizers 
should omit the port component and its ":" delimiter if port is empty or
 if its value would be the same as that of the scheme's default.</p><div id="rfc.iref.96"></div><div id="rfc.iref.97"></div><div id="rfc.iref.98"></div><div id="rfc.iref.99"></div><div id="rfc.iref.100"></div><div id="rfc.iref.101"></div><div id="rfc.iref.102"></div><div id="rfc.iref.103"></div><div id="rfc.iref.104"></div><div id="rfc.iref.105"></div><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3.</a>&nbsp;<a name="path" href="#path">Path</a></h2><p id="rfc.section.3.3.p.1">The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical <a href="#query">query component</a>,
 serves to identify a resource within the scope of the URI's scheme and 
naming authority (if any). The path is terminated by the first question 
mark ("?") or number sign ("#") character, or by the end of the URI.</p><div id="rfc.figure.u.16"></div><p>If
 a URI contains an authority component, then the path component must 
either be empty or begin with a slash ("/") character. If a URI does not
 contain an authority component, then the path cannot begin with two 
slash characters ("//"). In addition, a URI reference (<a href="#uri-reference" title="URI Reference">Section&nbsp;4.1</a>)
 may be a relative-path reference, in which case the first path segment 
cannot contain a colon (":") character. The ABNF requires five separate 
rules to disambiguate these cases, only one of which will match the path
 substring within a given URI reference. We use the generic term "path 
component" to describe the URI substring matched by the parser to one of
 these rules. <a name="rfc.iref.106"></a>  <a name="rfc.iref.107"></a>  <a name="rfc.iref.108"></a>  <a name="rfc.iref.109"></a>  <a name="rfc.iref.110"></a>  <a name="rfc.iref.111"></a>  <a name="rfc.iref.112"></a>  <a name="rfc.iref.113"></a>  <a name="rfc.iref.114"></a>  <a name="rfc.iref.115"></a> </p><pre>   path          = path-abempty    ; begins with "/" or is empty
                 / path-absolute   ; begins with "/" but not "//"
                 / path-noscheme   ; begins with a non-colon segment
                 / path-rootless   ; begins with a segment
                 / path-empty      ; zero characters

   path-abempty  = *( "/" segment )
   path-absolute = "/" [ segment-nz *( "/" segment ) ]
   path-noscheme = segment-nz-nc *( "/" segment )
   path-rootless = segment-nz *( "/" segment )
   path-empty    = 0&lt;pchar&gt;

   segment       = *pchar
   segment-nz    = 1*pchar
   segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                 ; non-zero-length segment without any colon ":"

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
</pre><p id="rfc.section.3.3.p.3">A path consists of a sequence of path 
segments separated by a slash ("/") character. A path is always defined 
for a URI, though the defined path may be empty (zero length). Use of 
the slash character to indicate hierarchy is only required when a URI 
will be used as the context for relative references. For example, the 
URI &lt;mailto:fred@example.com&gt; has a path of "fred@example.com", 
whereas the URI &lt;foo://info.example.com?fred&gt; has an empty path.</p><div id="rfc.iref.116"></div><p id="rfc.section.3.3.p.4">The
 path segments "." and "..", also known as dot-segments, are defined for
 relative reference within the path name hierarchy. They are intended 
for use at the beginning of a relative-path reference (<a href="#relative-ref" title="Relative Reference">Section&nbsp;4.2</a>)
 to indicate relative position within the hierarchical tree of names. 
This is similar to their role within some operating systems' file 
directory structures to indicate the current directory and parent 
directory, respectively. However, unlike in a file system, these 
dot-segments are only interpreted within the URI path hierarchy and are 
removed as part of the resolution process (<a href="#absolutize" title="Relative Resolution">Section&nbsp;5.2</a>).</p><p id="rfc.section.3.3.p.5">Aside
 from dot-segments in hierarchical paths, a path segment is considered 
opaque by the generic syntax. URI producing applications often use the 
reserved characters allowed in a segment to delimit scheme-specific or 
dereference-handler-specific subcomponents. For example, the semicolon 
(";") and equals ("=") reserved characters are often used to delimit 
parameters and parameter values applicable to that segment. The comma 
(",") reserved character is often used for similar purposes. For 
example, one URI producer might use a segment such as "name;v=1.1" to 
indicate a reference to version 1.1 of "name", whereas another might use
 a segment such as "name,1.1" to indicate the same. Parameter types may 
be defined by scheme-specific semantics, but in most cases the syntax of
 a parameter is specific to the implementation of the URI's 
dereferencing algorithm.</p><h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4.</a>&nbsp;<a name="query" href="#query">Query</a></h2><div id="rfc.figure.u.17"></div><p> <a name="rfc.iref.117"></a> The query component contains non-hierarchical data that, along with data in the <a href="#path">path component</a>,
 serves to identify a resource within the scope of the URI's scheme and 
naming authority (if any). The query component is indicated by the first
 question mark ("?") character and terminated by a number sign ("#") 
character or by the end of the URI. <a name="rfc.iref.118"></a>  <a name="rfc.iref.119"></a> </p><pre>   query       = *( pchar / "/" / "?" )
</pre><p id="rfc.section.3.4.p.2">The characters slash ("/") and 
question mark ("?") may represent data within the query component. 
Beware that some older, erroneous implementations may not handle such 
data correctly when it is used as the base URI for relative references (<a href="#base-uri" title="Establishing a Base URI">Section&nbsp;5.1</a>),
 apparently because they fail to distinguish query data from path data 
when looking for hierarchical separators. However, as query components 
are often used to carry identifying information in the form of 
"key=value" pairs and one frequently used value is a reference to 
another URI, it is sometimes better for usability to avoid 
percent-encoding those characters.</p><h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5.</a>&nbsp;<a name="fragment" href="#fragment">Fragment</a></h2><div id="rfc.figure.u.18"></div><p> <a name="rfc.iref.120"></a>
 The fragment identifier component of a URI allows indirect 
identification of a secondary resource by reference to a primary 
resource and additional identifying information. The identified 
secondary resource may be some portion or subset of the primary 
resource, some view on representations of the primary resource, or some 
other resource defined or described by those representations. A fragment
 identifier component is indicated by the presence of a number sign 
("#") character and terminated by the end of the URI. <a name="rfc.iref.121"></a>  <a name="rfc.iref.122"></a> </p><pre>   fragment    = *( pchar / "/" / "?" )
</pre><p id="rfc.section.3.5.p.2">The semantics of a fragment identifier
 are defined by the set of representations that might result from a 
retrieval action on the primary resource. The fragment's format and 
resolution is therefore dependent on the media type <a href="#RFC2046" title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</a>
 of a potentially retrieved representation, even though such a retrieval
 is only performed if the URI is dereferenced. If no such representation
 exists, then the semantics of the fragment are considered unknown and 
are effectively unconstrained. Fragment identifier semantics are 
independent of the URI scheme and thus cannot be redefined by scheme 
specifications.</p><p id="rfc.section.3.5.p.3">Individual media types 
may define their own restrictions on or structures within the fragment 
identifier syntax for specifying different types of subsets, views, or 
external references that are identifiable as secondary resources by that
 media type. If the primary resource has multiple representations, as is
 often the case for resources whose representation is selected based on 
attributes of the retrieval request (a.k.a., content negotiation), then 
whatever is identified by the fragment should be consistent across all 
of those representations. Each representation should either define the 
fragment so that it corresponds to the same secondary resource, 
regardless of how it is represented, or should leave the fragment 
undefined (i.e., not found).</p><p id="rfc.section.3.5.p.4">As with any 
URI, use of a fragment identifier component does not imply that a 
retrieval action will take place. A URI with a fragment identifier may 
be used to refer to the secondary resource without any implication that 
the primary resource is accessible or will ever be accessed.</p><p id="rfc.section.3.5.p.5">Fragment
 identifiers have a special role in information retrieval systems as the
 primary form of client-side indirect referencing, allowing an author to
 specifically identify aspects of an existing resource that are only 
indirectly provided by the resource owner. As such, the fragment 
identifier is not used in the scheme-specific processing of a URI; 
instead, the fragment identifier is separated from the rest of the URI 
prior to a dereference, and thus the identifying information within the 
fragment itself is dereferenced solely by the user agent, regardless of 
the URI scheme. Although this separate handling is often perceived to be
 a loss of information, particularly for accurate redirection of 
references as resources move over time, it also serves to prevent 
information providers from denying reference authors the right to refer 
to information within a resource selectively. Indirect referencing also 
provides additional flexibility and extensibility to systems that use 
URIs, as new media types are easier to define and deploy than new 
schemes of identification.</p><p id="rfc.section.3.5.p.6">The characters
 slash ("/") and question mark ("?") are allowed to represent data 
within the fragment identifier. Beware that some older, erroneous 
implementations may not handle this data correctly when it is used as 
the base URI for relative references (<a href="#base-uri" title="Establishing a Base URI">Section&nbsp;5.1</a>).</p><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a name="usage" href="#usage">Usage</a></h1><p id="rfc.section.4.p.1">When
 applications make reference to a URI, they do not always use the full 
form of reference defined by the "URI" syntax rule. To save space and 
take advantage of hierarchical locality, many Internet protocol elements
 and media type formats allow an abbreviation of a URI, whereas others 
restrict the syntax to a particular form of URI. We define the most 
common forms of reference syntax in this specification because they 
impact and depend upon the design of the generic syntax, requiring a 
uniform parsing algorithm in order to be interpreted consistently.</p><div id="rfc.iref.123"></div><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1.</a>&nbsp;<a name="uri-reference" href="#uri-reference">URI Reference</a></h2><div id="rfc.figure.u.19"></div><p>URI-reference is used to denote the most common usage of a resource identifier. <a name="rfc.iref.124"></a>  <a name="rfc.iref.125"></a>  <a name="rfc.iref.126"></a> </p><pre>   URI-reference = URI / relative-ref
</pre><p>A URI-reference is either a URI or a relative reference. If the
 URI-reference's prefix does not match the syntax of a scheme followed 
by its colon separator, then the URI-reference is a relative reference.</p><p id="rfc.section.4.1.p.2">A
 URI-reference is typically parsed first into the five URI components, 
in order to determine what components are present and whether the 
reference is relative. Then, each component is parsed for its subparts 
and their validation. The ABNF of URI-reference, along with the 
"first-match-wins" disambiguation rule, is sufficient to define a 
validating parser for the generic syntax. Readers familiar with regular 
expressions should see <a href="#regexp" title="Parsing a URI Reference with a Regular Expression">Appendix&nbsp;B</a> for an example of a non-validating URI-reference parser that will take any given string and extract the URI components.</p><div id="rfc.iref.127"></div><div id="rfc.iref.128"></div><div id="rfc.iref.129"></div><div id="rfc.iref.130"></div><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2.</a>&nbsp;<a name="relative-ref" href="#relative-ref">Relative Reference</a></h2><div id="rfc.figure.u.20"></div><p>A relative reference takes advantage of the hierarchical syntax (<a href="#hierarchical" title="Hierarchical Identifiers">Section&nbsp;1.2.3</a>) to express a URI reference relative to the name space of another hierarchical URI. <a name="rfc.iref.131"></a>  <a name="rfc.iref.132"></a>  <a name="rfc.iref.133"></a> </p><pre>   relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

   relative-part = "//" authority path-abempty
                 / path-absolute
                 / path-noscheme
                 / path-empty
</pre><p>The URI referred to by a relative reference, also known as the 
target URI, is obtained by applying the reference resolution algorithm 
of <a href="#reference-resolution" title="Reference Resolution">Section&nbsp;5</a>.</p><p id="rfc.section.4.2.p.2">A
 relative reference that begins with two slash characters is termed a 
network-path reference; such references are rarely used. A relative 
reference that begins with a single slash character is termed an 
absolute-path reference. A relative reference that does not begin with a
 slash character is termed a relative-path reference.</p><p id="rfc.section.4.2.p.3">A
 path segment that contains a colon character (e.g., "this:that") cannot
 be used as the first segment of a relative-path reference, as it would 
be mistaken for a scheme name. Such a segment must be preceded by a 
dot-segment (e.g., "./this:that") to make a relative-path reference.</p><div id="rfc.iref.134"></div><div id="rfc.iref.135"></div><h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3.</a>&nbsp;<a name="absolute-uri" href="#absolute-uri">Absolute URI</a></h2><div id="rfc.figure.u.21"></div><p>Some
 protocol elements allow only the absolute form of a URI without a 
fragment identifier. For example, defining a base URI for later use by 
relative references calls for an absolute-URI syntax rule that does not 
allow a fragment. <a name="rfc.iref.136"></a>  <a name="rfc.iref.137"></a>  <a name="rfc.iref.138"></a> </p><pre>   absolute-URI  = scheme ":" hier-part [ "?" query ]
</pre><p>URI scheme specifications must define their own syntax so that 
all strings matching their scheme-specific syntax will also match the 
&lt;absolute-URI&gt; grammar. Scheme specifications will not define 
fragment identifier syntax or usage, regardless of its applicability to 
resources identifiable via that scheme, as fragment identification is 
orthogonal to scheme definition. However, scheme specifications are 
encouraged to include a wide range of examples, including examples that 
show use of the scheme's URIs with fragment identifiers when such usage 
is appropriate.</p><div id="rfc.iref.139"></div><h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4.</a>&nbsp;<a name="same-document" href="#same-document">Same-Document Reference</a></h2><p id="rfc.section.4.4.p.1">When a URI reference refers to a URI that is, aside from its fragment component (if any), identical to the base URI (<a href="#base-uri" title="Establishing a Base URI">Section&nbsp;5.1</a>),
 that reference is called a "same-document" reference. The most frequent
 examples of same-document references are relative references that are 
empty or include only the number sign ("#") separator followed by a 
fragment identifier.</p><p id="rfc.section.4.4.p.2">When a same-document
 reference is dereferenced for a retrieval action, the target of that 
reference is defined to be within the same entity (representation, 
document, or message) as the reference; therefore, a dereference should 
not result in a new retrieval action.</p><p id="rfc.section.4.4.p.3">Normalization of the base and target URIs prior to their comparison, as described in Sections <a href="#normalize-syntax" title="Syntax-Based Normalization">6.2.2</a> and <a href="#normalize-scheme" title="Scheme-Based Normalization">6.2.3</a>,
 is allowed but rarely performed in practice. Normalization may increase
 the set of same-document references, which may be of benefit to some 
caching applications. As such, reference authors should not assume that a
 slightly different, though equivalent, reference URI will (or will not)
 be interpreted as a same-document reference by any given application.</p><div id="rfc.iref.140"></div><h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5.</a>&nbsp;<a name="suffix" href="#suffix">Suffix Reference</a></h2><p id="rfc.section.4.5.p.1">The
 URI syntax is designed for unambiguous reference to resources and 
extensibility via the URI scheme. However, as URI identification and 
usage have become commonplace, traditional media (television, radio, 
newspapers, billboards, etc.) have increasingly used a suffix of the URI
 as a reference, consisting of only the authority and path portions of 
the URI, such as</p><div id="rfc.figure.u.22"></div><pre>   www.w3.org/Addressing/
</pre><p id="rfc.section.4.5.p.3">or simply a DNS registered name on its
 own. Such references are primarily intended for human interpretation 
rather than for machines, with the assumption that context-based 
heuristics are sufficient to complete the URI (e.g., most registered 
names beginning with "www" are likely to have a URI prefix of 
"http://"). Although there is no standard set of heuristics for 
disambiguating a URI suffix, many client implementations allow them to 
be entered by the user and heuristically resolved.</p><p id="rfc.section.4.5.p.4">Although
 this practice of using suffix references is common, it should be 
avoided whenever possible and should never be used in situations where 
long-term references are expected. The heuristics noted above will 
change over time, particularly when a new URI scheme becomes popular, 
and are often incorrect when used out of context. Furthermore, they can 
lead to security issues along the lines of those described in <a href="#RFC1535" title="A Security Problem and Proposed Correction With Widely Deployed DNS Software">[RFC1535]</a>.</p><p id="rfc.section.4.5.p.5">As
 a URI suffix has the same syntax as a relative-path reference, a suffix
 reference cannot be used in contexts where a relative reference is 
expected. As a result, suffix references are limited to places where 
there is no defined base URI, such as dialog boxes and off-line 
advertisements.</p><div id="rfc.iref.141"></div><div id="rfc.iref.142"></div><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a name="reference-resolution" href="#reference-resolution">Reference Resolution</a></h1><p id="rfc.section.5.p.1">This
 section defines the process of resolving a URI reference within a 
context that allows relative references so that the result is a string 
matching the &lt;URI&gt; syntax rule of <a href="#components" title="Syntax Components">Section&nbsp;3</a>.</p><div id="rfc.iref.143"></div><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a>&nbsp;<a name="base-uri" href="#base-uri">Establishing a Base URI</a></h2><p id="rfc.section.5.1.p.1">The
 term "relative" implies that a "base URI" exists against which the 
relative reference is applied. Aside from fragment-only references (<a href="#same-document" title="Same-Document Reference">Section&nbsp;4.4</a>),
 relative references are only usable when a base URI is known. A base 
URI must be established by the parser prior to parsing URI references 
that might be relative. A base URI must conform to the 
&lt;absolute-URI&gt; syntax rule (<a href="#absolute-uri" title="Absolute URI">Section&nbsp;4.3</a>).
 If the base URI is obtained from a URI reference, then that reference 
must be converted to absolute form and stripped of any fragment 
component prior to its use as a base URI.</p><p id="rfc.section.5.1.p.2">The
 base URI of a reference can be established in one of four ways, 
discussed below in order of precedence. The order of precedence can be 
thought of in terms of layers, where the innermost defined base URI has 
the highest precedence. This can be visualized graphically as follows:</p><div id="rfc.figure.u.23"></div><pre>   .----------------------------------------------------------.
   |  .----------------------------------------------------.  |
   |  |  .----------------------------------------------.  |  |
   |  |  |  .----------------------------------------.  |  |  |
   |  |  |  |  .----------------------------------.  |  |  |  |
   |  |  |  |  |       &lt;relative-reference&gt;       |  |  |  |  |
   |  |  |  |  `----------------------------------'  |  |  |  |
   |  |  |  | (5.1.1) Base URI embedded in content   |  |  |  |
   |  |  |  `----------------------------------------'  |  |  |
   |  |  | (5.1.2) Base URI of the encapsulating entity |  |  |
   |  |  |         (message, representation, or none)   |  |  |
   |  |  `----------------------------------------------'  |  |
   |  | (5.1.3) URI used to retrieve the entity            |  |
   |  `----------------------------------------------------'  |
   | (5.1.4) Default Base URI (application-dependent)         |
   `----------------------------------------------------------'
</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1.</a>&nbsp;<a name="base-content" href="#base-content">Base URI Embedded in Content</a></h3><p id="rfc.section.5.1.1.p.1">Within
 certain media types, a base URI for relative references can be embedded
 within the content itself so that it can be readily obtained by a 
parser. This can be useful for descriptive documents, such as tables of 
contents, which may be transmitted to others through protocols other 
than their usual retrieval context (e.g., email or USENET news).</p><p id="rfc.section.5.1.1.p.2">It
 is beyond the scope of this specification to specify how, for each 
media type, a base URI can be embedded. The appropriate syntax, when 
available, is described by the data format specification associated with
 each media type.</p><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2.</a>&nbsp;<a name="base-encapsulated" href="#base-encapsulated">Base URI from the Encapsulating Entity</a></h3><p id="rfc.section.5.1.2.p.1">If
 no base URI is embedded, the base URI is defined by the 
representation's retrieval context. For a document that is enclosed 
within another entity, such as a message or archive, the retrieval 
context is that entity. Thus, the default base URI of a representation 
is the base URI of the entity in which the representation is 
encapsulated.</p><p id="rfc.section.5.1.2.p.2">A mechanism for embedding a base URI within MIME container types (e.g., the message and multipart types) is defined by MHTML <a href="#RFC2557" title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</a>.
 Protocols that do not use the MIME message header syntax, but that do 
allow some form of tagged metadata to be included within messages, may 
define their own syntax for defining a base URI as part of a message.</p><h3 id="rfc.section.5.1.3"><a href="#rfc.section.5.1.3">5.1.3.</a>&nbsp;<a name="base-retrieval" href="#base-retrieval">Base URI from the Retrieval URI</a></h3><p id="rfc.section.5.1.3.p.1">If
 no base URI is embedded and the representation is not encapsulated 
within some other entity, then, if a URI was used to retrieve the 
representation, that URI shall be considered the base URI. Note that if 
the retrieval was the result of a redirected request, the last URI used 
(i.e., the URI that resulted in the actual retrieval of the 
representation) is the base URI.</p><h3 id="rfc.section.5.1.4"><a href="#rfc.section.5.1.4">5.1.4.</a>&nbsp;<a name="base-default" href="#base-default">Default Base URI</a></h3><p id="rfc.section.5.1.4.p.1">If
 none of the conditions described above apply, then the base URI is 
defined by the context of the application. As this definition is 
necessarily application-dependent, failing to define a base URI by using
 one of the other methods may result in the same content being 
interpreted differently by different types of applications.</p><p id="rfc.section.5.1.4.p.2">A
 sender of a representation containing relative references is 
responsible for ensuring that a base URI for those references can be 
established. Aside from fragment-only references, relative references 
can only be used reliably in situations where the base URI is well 
defined.</p><h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2.</a>&nbsp;<a name="absolutize" href="#absolutize">Relative Resolution</a></h2><p id="rfc.section.5.2.p.1">This
 section describes an algorithm for converting a URI reference that 
might be relative to a given base URI into the parsed components of the 
reference's target. The components can then be recomposed, as described 
in <a href="#recomposition" title="Component Recomposition">Section&nbsp;5.3</a>,
 to form the target URI. This algorithm provides definitive results that
 can be used to test the output of other implementations. Applications 
may implement relative reference resolution by using some other 
algorithm, provided that the results match what would be given by this 
one.</p><h3 id="rfc.section.5.2.1"><a href="#rfc.section.5.2.1">5.2.1.</a>&nbsp;<a name="relative-base" href="#relative-base">Pre-parse the Base URI</a></h3><p id="rfc.section.5.2.1.p.1">The base URI (Base) is established according to the procedure of <a href="#base-uri" title="Establishing a Base URI">Section&nbsp;5.1</a> and parsed into the five main components described in <a href="#components" title="Syntax Components">Section&nbsp;3</a>.
 Note that only the scheme component is required to be present in a base
 URI; the other components may be empty or undefined. A component is 
undefined if its associated delimiter does not appear in the URI 
reference; the path component is never undefined, though it may be 
empty.</p><p id="rfc.section.5.2.1.p.2">Normalization of the base URI, as described in Sections <a href="#normalize-syntax" title="Syntax-Based Normalization">6.2.2</a> and <a href="#normalize-scheme" title="Scheme-Based Normalization">6.2.3</a>, is optional. A URI reference must be transformed to its target URI before it can be normalized.</p><h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2.</a>&nbsp;<a name="relative-transform" href="#relative-transform">Transform References</a></h3><div id="rfc.figure.u.24"></div><p>For each URI reference (R), the following pseudocode describes an algorithm for transforming R into its target URI (T):</p>  <pre>   -- The URI reference is parsed into the five URI components
   --
   (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);

   -- A non-strict parser may ignore a scheme in the reference
   -- if it is identical to the base URI's scheme.
   --
   if ((not strict) and (R.scheme == Base.scheme)) then
      undefine(R.scheme);
   endif;

   if defined(R.scheme) then
      T.scheme    = R.scheme;
      T.authority = R.authority;
      T.path      = remove_dot_segments(R.path);
      T.query     = R.query;
   else
      if defined(R.authority) then
         T.authority = R.authority;
         T.path      = remove_dot_segments(R.path);
         T.query     = R.query;
      else
         if (R.path == "") then
            T.path = Base.path;
            if defined(R.query) then
               T.query = R.query;
            else
               T.query = Base.query;
            endif;
         else
            if (R.path starts-with "/") then
               T.path = remove_dot_segments(R.path);
            else
               T.path = merge(Base.path, R.path);
               T.path = remove_dot_segments(T.path);
            endif;
            T.query = R.query;
         endif;
         T.authority = Base.authority;
      endif;
      T.scheme = Base.scheme;
   endif;

   T.fragment = R.fragment;
</pre><div id="rfc.iref.144"></div><h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3.</a>&nbsp;<a name="relative-merge" href="#relative-merge">Merge Paths</a></h3><p id="rfc.section.5.2.3.p.1">The
 pseudocode above refers to a "merge" routine for merging a 
relative-path reference with the path of the base URI. This is 
accomplished as follows: </p><ul><li>If the base URI has a defined 
authority component and an empty path, then return a string consisting 
of "/" concatenated with the reference's path; otherwise,</li><li>return
 a string consisting of the reference's path component appended to all 
but the last segment of the base URI's path (i.e., excluding any 
characters after the right-most "/" in the base URI path, or excluding 
the entire base URI path if it does not contain any "/" characters).</li></ul><div id="rfc.iref.145"></div><h3 id="rfc.section.5.2.4"><a href="#rfc.section.5.2.4">5.2.4.</a>&nbsp;<a name="relative-dot-segments" href="#relative-dot-segments">Remove Dot Segments</a></h3><p id="rfc.section.5.2.4.p.1">The
 pseudocode also refers to a "remove_dot_segments" routine for 
interpreting and removing the special "." and ".." complete path 
segments from a referenced path. This is done after the path is 
extracted from a reference, whether or not the path was relative, in 
order to remove any invalid or extraneous dot-segments prior to forming 
the target URI. Although there are many ways to accomplish this removal 
process, we describe a simple method using two string buffers. </p><ol><li>The input buffer is initialized with the now-appended path components and the output buffer is initialized to the empty string.</li><li>While the input buffer is not empty, loop as follows: <ol style="list-style-type: upper-alpha"><li>If the input buffer begins with a prefix of "../" or "./", then remove that prefix from the input buffer; otherwise,</li><li>if
 the input buffer begins with a prefix of "/./" or "/.", where "." is a 
complete path segment, then replace that prefix with "/" in the input 
buffer; otherwise,</li><li>if the input buffer begins with a prefix of 
"/../" or "/..", where ".." is a complete path segment, then replace 
that prefix with "/" in the input buffer and remove the last segment and
 its preceding "/" (if any) from the output buffer; otherwise,</li><li>if the input buffer consists only of "." or "..", then remove that from the input buffer; otherwise,</li><li>move
 the first path segment in the input buffer to the end of the output 
buffer, including the initial "/" character (if any) and any subsequent 
characters up to, but not including, the next "/" character or the end 
of the input buffer.</li></ol> </li><li>Finally, the output buffer is returned as the result of remove_dot_segments.</li></ol><p id="rfc.section.5.2.4.p.2">Note
 that dot-segments are intended for use in URI references to express an 
identifier relative to the hierarchy of names in the base URI. The 
remove_dot_segments algorithm respects that hierarchy by removing extra 
dot-segments rather than treat them as an error or leaving them to be 
misinterpreted by dereference implementations.</p><div id="rfc.figure.u.25"></div><p>The
 following illustrates how the above steps are applied for two examples 
of merged paths, showing the state of the two buffers after each step.</p><pre>   STEP   OUTPUT BUFFER         INPUT BUFFER

    1 :                         /a/b/c/./../../g
    2E:   /a                    /b/c/./../../g
    2E:   /a/b                  /c/./../../g
    2E:   /a/b/c                /./../../g
    2B:   /a/b/c                /../../g
    2C:   /a/b                  /../g
    2C:   /a                    /g
    2E:   /a/g

   STEP   OUTPUT BUFFER         INPUT BUFFER

    1 :                         mid/content=5/../6
    2E:   mid                   /content=5/../6
    2E:   mid/content=5         /../6
    2C:   mid                   /6
    2E:   mid/6
</pre><p>Some applications may find it more efficient to implement the 
remove_dot_segments algorithm by using two segment stacks rather than 
strings.</p><p id="rfc.section.5.2.4.p.4"> </p><dl><dd style="margin-top: .5em">Note:
 Beware that some older, erroneous implementations will fail to separate
 a reference's query component from its path component prior to merging 
the base and reference paths, resulting in an interoperability failure 
if the query component contains the strings "/../" or "/./".</dd></dl><h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3.</a>&nbsp;<a name="recomposition" href="#recomposition">Component Recomposition</a></h2><div id="rfc.figure.u.26"></div><p>Parsed URI components can be recomposed to obtain the corresponding URI reference string. Using pseudocode, this would be:</p><pre>   result = ""

   if defined(scheme) then
      append scheme to result;
      append ":" to result;
   endif;

   if defined(authority) then
      append "//" to result;
      append authority to result;
   endif;

   append path to result;

   if defined(query) then
      append "?" to result;
      append query to result;
   endif;

   if defined(fragment) then
      append "#" to result;
      append fragment to result;
   endif;

   return result;
</pre><p>Note that we are careful to preserve the distinction between a 
component that is undefined, meaning that its separator was not present 
in the reference, and a component that is empty, meaning that the 
separator was present and was immediately followed by the next component
 separator or the end of the reference.</p><h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4.</a>&nbsp;<a name="reference-examples" href="#reference-examples">Reference Resolution Examples</a></h2><p id="rfc.section.5.4.p.1">Within a representation with a well defined base URI of</p><div id="rfc.figure.u.27"></div><pre>   http://a/b/c/d;p?q
</pre><p id="rfc.section.5.4.p.3">a relative reference is transformed to its target URI as follows.</p><h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1.</a>&nbsp;<a name="relative-normal" href="#relative-normal">Normal Examples</a></h3><div id="rfc.figure.u.28"></div><pre>   "g:h"           =  "g:h"
   "g"             =  "http://a/b/c/g"
   "./g"           =  "http://a/b/c/g"
   "g/"            =  "http://a/b/c/g/"
   "/g"            =  "http://a/g"
   "//g"           =  "http://g"
   "?y"            =  "http://a/b/c/d;p?y"
   "g?y"           =  "http://a/b/c/g?y"
   "#s"            =  "http://a/b/c/d;p?q#s"
   "g#s"           =  "http://a/b/c/g#s"
   "g?y#s"         =  "http://a/b/c/g?y#s"
   ";x"            =  "http://a/b/c/;x"
   "g;x"           =  "http://a/b/c/g;x"
   "g;x?y#s"       =  "http://a/b/c/g;x?y#s"
   ""              =  "http://a/b/c/d;p?q"
   "."             =  "http://a/b/c/"
   "./"            =  "http://a/b/c/"
   ".."            =  "http://a/b/"
   "../"           =  "http://a/b/"
   "../g"          =  "http://a/b/g"
   "../.."         =  "http://a/"
   "../../"        =  "http://a/"
   "../../g"       =  "http://a/g"
</pre><h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2.</a>&nbsp;<a name="relative-abnormal" href="#relative-abnormal">Abnormal Examples</a></h3><p id="rfc.section.5.4.2.p.1">Although
 the following abnormal examples are unlikely to occur in normal 
practice, all URI parsers should be capable of resolving them 
consistently. Each example uses the same base as that above.</p><p id="rfc.section.5.4.2.p.2">Parsers
 must be careful in handling cases where there are more ".." segments in
 a relative-path reference than there are hierarchical levels in the 
base URI's path. Note that the ".." syntax cannot be used to change the 
authority component of a URI.</p><div id="rfc.figure.u.29"></div><pre>   "../../../g"    =  "http://a/g"
   "../../../../g" =  "http://a/g"
</pre><p id="rfc.section.5.4.2.p.4">Similarly, parsers must remove the 
dot-segments "." and ".." when they are complete components of a path, 
but not when they are only part of a segment.</p><div id="rfc.figure.u.30"></div><pre>   "/./g"          =  "http://a/g"
   "/../g"         =  "http://a/g"
   "g."            =  "http://a/b/c/g."
   ".g"            =  "http://a/b/c/.g"
   "g.."           =  "http://a/b/c/g.."
   "..g"           =  "http://a/b/c/..g"
</pre><p id="rfc.section.5.4.2.p.6">Less likely are cases where the 
relative reference uses unnecessary or nonsensical forms of the "." and 
".." complete path segments.</p><div id="rfc.figure.u.31"></div><pre>   "./../g"        =  "http://a/b/g"
   "./g/."         =  "http://a/b/c/g/"
   "g/./h"         =  "http://a/b/c/g/h"
   "g/../h"        =  "http://a/b/c/h"
   "g;x=1/./y"     =  "http://a/b/c/g;x=1/y"
   "g;x=1/../y"    =  "http://a/b/c/y"
</pre><p id="rfc.section.5.4.2.p.8">Some applications fail to separate 
the reference's query and/or fragment components from the path component
 before merging it with the base path and removing dot-segments. This 
error is rarely noticed, as typical usage of a fragment never includes 
the hierarchy ("/") character and the query component is not normally 
used within relative references.</p><div id="rfc.figure.u.32"></div><pre>   "g?y/./x"       =  "http://a/b/c/g?y/./x"
   "g?y/../x"      =  "http://a/b/c/g?y/../x"
   "g#s/./x"       =  "http://a/b/c/g#s/./x"
   "g#s/../x"      =  "http://a/b/c/g#s/../x"
</pre><p id="rfc.section.5.4.2.p.10">Some parsers allow the scheme name 
to be present in a relative reference if it is the same as the base URI 
scheme. This is considered to be a loophole in prior specifications of 
partial URI <a href="#RFC1630" title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</a>. Its use should be avoided but is allowed for backward compatibility.</p><div id="rfc.figure.u.33"></div><pre>   "http:g"        =  "http:g"         ; for strict parsers
                   /  "http://a/b/c/g" ; for backward compatibility
</pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a name="comparison" href="#comparison">Normalization and Comparison</a></h1><p id="rfc.section.6.p.1">One
 of the most common operations on URIs is simple comparison: determining
 whether two URIs are equivalent without using the URIs to access their 
respective resource(s). A comparison is performed every time a response 
cache is accessed, a browser checks its history to color a link, or an 
XML parser processes tags within a namespace. Extensive normalization 
prior to comparison of URIs is often used by spiders and indexing 
engines to prune a search space or to reduce duplication of request 
actions and response storage.</p><p id="rfc.section.6.p.2">URI 
comparison is performed for some particular purpose. Protocols or 
implementations that compare URIs for different purposes will often be 
subject to differing design trade-offs in regards to how much effort 
should be spent in reducing aliased identifiers. This section describes 
various methods that may be used to compare URIs, the trade-offs between
 them, and the types of applications that might use them.</p><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1.</a>&nbsp;<a name="equivalence" href="#equivalence">Equivalence</a></h2><p id="rfc.section.6.1.p.1">Because
 URIs exist to identify resources, presumably they should be considered 
equivalent when they identify the same resource. However, this 
definition of equivalence is not of much practical use, as there is no 
way for an implementation to compare two resources unless it has full 
knowledge or control of them. For this reason, determination of 
equivalence or difference of URIs is based on string comparison, perhaps
 augmented by reference to additional rules provided by URI scheme 
definitions. We use the terms "different" and "equivalent" to describe 
the possible outcomes of such comparisons, but there are many 
application-dependent versions of equivalence.</p><p id="rfc.section.6.1.p.2">Even
 though it is possible to determine that two URIs are equivalent, URI 
comparison is not sufficient to determine whether two URIs identify 
different resources. For example, an owner of two different domain names
 could decide to serve the same resource from both, resulting in two 
different URIs. Therefore, comparison methods are designed to minimize 
false negatives while strictly avoiding false positives.</p><p id="rfc.section.6.1.p.3">In
 testing for equivalence, applications should not directly compare 
relative references; the references should be converted to their 
respective target URIs before comparison. When URIs are compared to 
select (or avoid) a network action, such as retrieval of a 
representation, fragment components (if any) should be excluded from the
 comparison.</p><h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2.</a>&nbsp;<a name="comparison-ladder" href="#comparison-ladder">Comparison Ladder</a></h2><p id="rfc.section.6.2.p.1">A
 variety of methods are used in practice to test URI equivalence. These 
methods fall into a range, distinguished by the amount of processing 
required and the degree to which the probability of false negatives is 
reduced. As noted above, false negatives cannot be eliminated. In 
practice, their probability can be reduced, but this reduction requires 
more processing and is not cost-effective for all applications.</p><p id="rfc.section.6.2.p.2">If
 this range of comparison practices is considered as a ladder, the 
following discussion will climb the ladder, starting with practices that
 are cheap but have a relatively higher chance of producing false 
negatives, and proceeding to those that have higher computational cost 
and lower risk of false negatives.</p><h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1.</a>&nbsp;<a name="comparison-string" href="#comparison-string">Simple String Comparison</a></h3><p id="rfc.section.6.2.1.p.1">If
 two URIs, when considered as character strings, are identical, then it 
is safe to conclude that they are equivalent. This type of equivalence 
test has very low computational cost and is in wide use in a variety of 
applications, particularly in the domain of parsing.</p><p id="rfc.section.6.2.1.p.2">Testing
 strings for equivalence requires some basic precautions. This procedure
 is often referred to as "bit-for-bit" or "byte-for-byte" comparison, 
which is potentially misleading. Testing strings for equality is 
normally based on pair comparison of the characters that make up the 
strings, starting from the first and proceeding until both strings are 
exhausted and all characters are found to be equal, until a pair of 
characters compares unequal, or until one of the strings is exhausted 
before the other.</p><p id="rfc.section.6.2.1.p.3">This character 
comparison requires that each pair of characters be put in comparable 
form. For example, should one URI be stored in a byte array in EBCDIC 
encoding and the second in a Java String object (UTF-16), bit-for-bit 
comparisons applied naively will produce errors. It is better to speak 
of equality on a character-for-character basis rather than on a 
byte-for-byte or bit-for-bit basis. In practical terms, 
character-by-character comparisons should be done codepoint-by-codepoint
 after conversion to a common character encoding.</p><p id="rfc.section.6.2.1.p.4">False
 negatives are caused by the production and use of URI aliases. 
Unnecessary aliases can be reduced, regardless of the comparison method,
 by consistently providing URI references in an already-normalized form 
(i.e., a form identical to what would be produced after normalization is
 applied, as described below).</p><p id="rfc.section.6.2.1.p.5">Protocols
 and data formats often limit some URI comparisons to simple string 
comparison, based on the theory that people and implementations will, in
 their own best interest, be consistent in providing URI references, or 
at least consistent enough to negate any efficiency that might be 
obtained from further normalization.</p><h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2.</a>&nbsp;<a name="normalize-syntax" href="#normalize-syntax">Syntax-Based Normalization</a></h3><div id="rfc.figure.u.34"></div><p>Implementations
 may use logic based on the definitions provided by this specification 
to reduce the probability of false negatives. This processing is 
moderately higher in cost than character-for-character string 
comparison. For example, an application using this approach could 
reasonably consider the following two URIs equivalent:</p><pre>   example://a/b/c/%7Bfoo%7D
   eXAMPLE://a/./b/../b/%63/%7bfoo%7d
</pre><p>Web user agents, such as browsers, typically apply this type of
 URI normalization when determining whether a cached response is 
available. Syntax-based normalization includes such techniques as case 
normalization, percent-encoding normalization, and removal of 
dot-segments.</p><h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1.</a>&nbsp;<a name="normalize-case" href="#normalize-case">Case Normalization</a></h4><p id="rfc.section.6.2.2.1.p.1">For
 all URIs, the hexadecimal digits within a percent-encoding triplet 
(e.g., "%3a" versus "%3A") are case-insensitive and therefore should be 
normalized to use uppercase letters for the digits A-F.</p><p id="rfc.section.6.2.2.1.p.2">When
 a URI uses components of the generic syntax, the component syntax 
equivalence rules always apply; namely, that the scheme and host are 
case-insensitive and therefore should be normalized to lowercase. For 
example, the URI &lt;HTTP://www.EXAMPLE.com/&gt; is equivalent to 
&lt;http://www.example.com/&gt;. The other generic syntax components are
 assumed to be case-sensitive unless specifically defined otherwise by 
the scheme (see <a href="#normalize-scheme" title="Scheme-Based Normalization">Section&nbsp;6.2.3</a>).</p><h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2.</a>&nbsp;<a name="normalize-encoding" href="#normalize-encoding">Percent-Encoding Normalization</a></h4><p id="rfc.section.6.2.2.2.p.1">The percent-encoding mechanism (<a href="#percent-encoding" title="Percent-Encoding">Section&nbsp;2.1</a>)
 is a frequent source of variance among otherwise identical URIs. In 
addition to the case normalization issue noted above, some URI producers
 percent-encode octets that do not require percent-encoding, resulting 
in URIs that are equivalent to their non-encoded counterparts. These 
URIs should be normalized by decoding any percent-encoded octet that 
corresponds to an unreserved character, as described in <a href="#unreserved" title="Unreserved Characters">Section&nbsp;2.3</a>.</p><h4 id="rfc.section.6.2.2.3"><a href="#rfc.section.6.2.2.3">6.2.2.3.</a>&nbsp;<a name="normalize-path" href="#normalize-path">Path Segment Normalization</a></h4><p id="rfc.section.6.2.2.3.p.1">The complete path segments "." and ".." are intended only for use within relative references (<a href="#uri-reference" title="URI Reference">Section&nbsp;4.1</a>) and are removed as part of the reference resolution process (<a href="#absolutize" title="Relative Resolution">Section&nbsp;5.2</a>).
 However, some deployed implementations incorrectly assume that 
reference resolution is not necessary when the reference is already a 
URI and thus fail to remove dot-segments when they occur in non-relative
 paths. URI normalizers should remove dot-segments by applying the 
remove_dot_segments algorithm to the path, as described in <a href="#relative-dot-segments" title="Remove Dot Segments">Section&nbsp;5.2.4</a>.</p><h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3.</a>&nbsp;<a name="normalize-scheme" href="#normalize-scheme">Scheme-Based Normalization</a></h3><div id="rfc.figure.u.35"></div><p>The
 syntax and semantics of URIs vary from scheme to scheme, as described 
by the defining specification for each scheme. Implementations may use 
scheme-specific rules, at further processing cost, to reduce the 
probability of false negatives. For example, because the "http" scheme 
makes use of an authority component, has a default port of "80", and 
defines an empty path to be equivalent to "/", the following four URIs 
are equivalent:</p><pre>   http://example.com
   http://example.com/
   http://example.com:/
   http://example.com:80/
</pre><p>In general, a URI that uses the generic syntax for authority 
with an empty path should be normalized to a path of "/". Likewise, an 
explicit ":port", for which the port is empty or the default for the 
scheme, is equivalent to one where the port and its ":" delimiter are 
elided and thus should be removed by scheme-based normalization. For 
example, the second URI above is the normal form for the "http" scheme.</p><p id="rfc.section.6.2.3.p.2">Another
 case where normalization varies by scheme is in the handling of an 
empty authority component or empty host subcomponent. For many scheme 
specifications, an empty authority or host is considered an error; for 
others, it is considered equivalent to "localhost" or the end-user's 
host. When a scheme defines a default for authority and a URI reference 
to that default is desired, the reference should be normalized to an 
empty authority for the sake of uniformity, brevity, and 
internationalization. If, however, either the userinfo or port 
subcomponents are non-empty, then the host should be given explicitly 
even if it matches the default.</p><p id="rfc.section.6.2.3.p.3">Normalization
 should not remove delimiters when their associated component is empty 
unless licensed to do so by the scheme specification. For example, the 
URI "http://example.com/?" cannot be assumed to be equivalent to any of 
the examples above. Likewise, the presence or absence of delimiters 
within a userinfo subcomponent is usually significant to its 
interpretation. The fragment component is not subject to any 
scheme-based normalization; thus, two URIs that differ only by the 
suffix "#" are considered different regardless of the scheme.</p><p id="rfc.section.6.2.3.p.4">Some
 schemes define additional subcomponents that consist of 
case-insensitive data, giving an implicit license to normalizers to 
convert this data to a common case (e.g., all lowercase). For example, 
URI schemes that define a subcomponent of path to contain an Internet 
hostname, such as the "mailto" URI scheme, cause that subcomponent to be
 case-insensitive and thus subject to case normalization (e.g., 
"mailto:Joe@Example.COM" is equivalent to "mailto:Joe@example.com", even
 though the generic syntax considers the path component to be 
case-sensitive).</p><p id="rfc.section.6.2.3.p.5">Other scheme-specific normalizations are possible.</p><h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4.</a>&nbsp;<a name="normalize-protocol" href="#normalize-protocol">Protocol-Based Normalization</a></h3><div id="rfc.figure.u.36"></div><p>Substantial
 effort to reduce the incidence of false negatives is often 
cost-effective for web spiders. Therefore, they implement even more 
aggressive techniques in URI comparison. For example, if they observe 
that a URI such as</p><pre>   http://example.com/data
</pre><div id="rfc.figure.u.37"></div><p>redirects to a URI differing only in the trailing slash</p><pre>   http://example.com/data/
</pre><p>they will likely regard the two as equivalent in the future. 
This kind of technique is only appropriate when equivalence is clearly 
indicated by both the result of accessing the resources and the common 
conventions of their scheme's dereference algorithm (in this case, use 
of redirection by HTTP origin servers to avoid problems with relative 
references).</p><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a name="security" href="#security">Security Considerations</a></h1><p id="rfc.section.7.p.1">A
 URI does not in itself pose a security threat. However, as URIs are 
often used to provide a compact set of instructions for access to 
network resources, care must be taken to properly interpret the data 
within a URI, to prevent that data from causing unintended access, and 
to avoid including data that should not be revealed in plain text.</p><h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1.</a>&nbsp;<a name="security-reliability" href="#security-reliability">Reliability and Consistency</a></h2><p id="rfc.section.7.1.p.1">There
 is no guarantee that once a URI has been used to retrieve information, 
the same information will be retrievable by that URI in the future. Nor 
is there any guarantee that the information retrievable via that URI in 
the future will be observably similar to that retrieved in the past. The
 URI syntax does not constrain how a given scheme or authority 
apportions its namespace or maintains it over time. Such guarantees can 
only be obtained from the person(s) controlling that namespace and the 
resource in question. A specific URI scheme may define additional 
semantics, such as name persistence, if those semantics are required of 
all naming authorities for that scheme.</p><h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2.</a>&nbsp;<a name="security-malicious" href="#security-malicious">Malicious Construction</a></h2><p id="rfc.section.7.2.p.1">It
 is sometimes possible to construct a URI so that an attempt to perform a
 seemingly harmless, idempotent operation, such as the retrieval of a 
representation, will in fact cause a possibly damaging remote operation.
 The unsafe URI is typically constructed by specifying a port number 
other than that reserved for the network protocol in question. The 
client unwittingly contacts a site running a different protocol service,
 and data within the URI contains instructions that, when interpreted 
according to this other protocol, cause an unexpected operation. A 
frequent example of such abuse has been the use of a protocol-based 
scheme with a port component of "25", thereby fooling user agent 
software into sending an unintended or impersonating message via an SMTP
 server.</p><p id="rfc.section.7.2.p.2">Applications should prevent 
dereference of a URI that specifies a TCP port number within the 
"well-known port" range (0 - 1023) unless the protocol being used to 
dereference that URI is compatible with the protocol expected on that 
well-known port. Although IANA maintains a registry of well-known ports,
 applications should make such restrictions user-configurable to avoid 
preventing the deployment of new services.</p><p id="rfc.section.7.2.p.3">When
 a URI contains percent-encoded octets that match the delimiters for a 
given resolution or dereference protocol (for example, CR and LF 
characters for the TELNET protocol), these percent-encodings must not be
 decoded before transmission across that protocol. Transfer of the 
percent-encoding, which might violate the protocol, is less harmful than
 allowing decoded octets to be interpreted as additional operations or 
parameters, perhaps triggering an unexpected and possibly harmful remote
 operation.</p><h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3.</a>&nbsp;<a name="security-transcoding" href="#security-transcoding">Back-End Transcoding</a></h2><p id="rfc.section.7.3.p.1">When
 a URI is dereferenced, the data within it is often parsed by both the 
user agent and one or more servers. In HTTP, for example, a typical user
 agent will parse a URI into its five major components, access the 
authority's server, and send it the data within the authority, path, and
 query components. A typical server will take that information, parse 
the path into segments and the query into key/value pairs, and then 
invoke implementation-specific handlers to respond to the request. As a 
result, a common security concern for server implementations that handle
 a URI, either as a whole or split into separate components, is proper 
interpretation of the octet data represented by the characters and 
percent-encodings within that URI.</p><p id="rfc.section.7.3.p.2">Percent-encoded
 octets must be decoded at some point during the dereference process. 
Applications must split the URI into its components and subcomponents 
prior to decoding the octets, as otherwise the decoded octets might be 
mistaken for delimiters. Security checks of the data within a URI should
 be applied after decoding the octets. Note, however, that the "%00" 
percent-encoding (NUL) may require special handling and should be 
rejected if the application is not expecting to receive raw data within a
 component.</p><p id="rfc.section.7.3.p.3">Special care should be taken 
when the URI path interpretation process involves the use of a back-end 
file system or related system functions. File systems typically assign 
an operational meaning to special characters, such as the "/", "\", ":",
 "[", and "]" characters, and to special device names like ".", "..", 
"...", "aux", "lpt", etc. In some cases, merely testing for the 
existence of such a name will cause the operating system to pause or 
invoke unrelated system calls, leading to significant security concerns 
regarding denial of service and unintended data transfer. It would be 
impossible for this specification to list all such significant 
characters and device names. Implementers should research the reserved 
names and characters for the types of storage device that may be 
attached to their applications and restrict the use of data obtained 
from URI components accordingly.</p><h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4.</a>&nbsp;<a name="security-ipv4" href="#security-ipv4">Rare IP Address Formats</a></h2><p id="rfc.section.7.4.p.1">Although
 the URI syntax for IPv4address only allows the common dotted-decimal 
form of IPv4 address literal, many implementations that process URIs 
make use of platform-dependent system routines, such as gethostbyname() 
and inet_aton(), to translate the string literal to an actual IP 
address. Unfortunately, such system routines often allow and process a 
much larger set of formats than those described in <a href="#host" title="Host">Section&nbsp;3.2.2</a>.</p><p id="rfc.section.7.4.p.2">For
 example, many implementations allow dotted forms of three numbers, 
wherein the last part is interpreted as a 16-bit quantity and placed in 
the right-most two bytes of the network address (e.g., a Class B 
network). Likewise, a dotted form of two numbers means that the last 
part is interpreted as a 24-bit quantity and placed in the right-most 
three bytes of the network address (Class A), and a single number 
(without dots) is interpreted as a 32-bit quantity and stored directly 
in the network address. Adding further to the confusion, some 
implementations allow each dotted part to be interpreted as decimal, 
octal, or hexadecimal, as specified in the C language (i.e., a leading 
0x or 0X implies hexadecimal; a leading 0 implies octal; otherwise, the 
number is interpreted as decimal).</p><p id="rfc.section.7.4.p.3">These 
additional IP address formats are not allowed in the URI syntax due to 
differences between platform implementations. However, they can become a
 security concern if an application attempts to filter access to 
resources based on the IP address in string literal format. If this 
filtering is performed, literals should be converted to numeric form and
 filtered based on the numeric value, and not on a prefix or suffix of 
the string form.</p><h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5.</a>&nbsp;<a name="security-sensitive" href="#security-sensitive">Sensitive Information</a></h2><p id="rfc.section.7.5.p.1">URI
 producers should not provide a URI that contains a username or password
 that is intended to be secret. URIs are frequently displayed by 
browsers, stored in clear text bookmarks, and logged by user agent 
history and intermediary applications (proxies). A password appearing 
within the userinfo component is deprecated and should be considered an 
error (or simply ignored) except in those rare cases where the 
'password' parameter is intended to be public.</p><h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6.</a>&nbsp;<a name="security-semantic" href="#security-semantic">Semantic Attacks</a></h2><div id="rfc.figure.u.38"></div><p>Because
 the userinfo subcomponent is rarely used and appears before the host in
 the authority component, it can be used to construct a URI intended to 
mislead a human user by appearing to identify one (trusted) naming 
authority while actually identifying a different authority hidden behind
 the noise. For example</p><pre>   ftp://cnn.example.com&amp;story=breaking_news@10.0.0.1/top_story.htm
</pre><p>might lead a human user to assume that the host is 
'cnn.example.com', whereas it is actually '10.0.0.1'. Note that a 
misleading userinfo subcomponent could be much longer than the example 
above.</p><p id="rfc.section.7.6.p.2">A misleading URI, such as that 
above, is an attack on the user's preconceived notions about the meaning
 of a URI rather than an attack on the software itself. User agents may 
be able to reduce the impact of such attacks by distinguishing the 
various components of the URI when they are rendered, such as by using a
 different color or tone to render userinfo if any is present, though 
there is no panacea. More information on URI-based semantic attacks can 
be found in <a href="#Siedzik" title="Semantic Attacks: What's in a URL?">[Siedzik]</a>.</p><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a name="IANA" href="#IANA">IANA Considerations</a></h1><p id="rfc.section.8.p.1">URI scheme names, as defined by &lt;scheme&gt; in <a href="#scheme" title="Scheme">Section&nbsp;3.1</a>, form a registered namespace that is managed by IANA according to the procedures defined in <a href="#BCP35" title="Registration Procedures for URL Scheme Names">[BCP35]</a>. No IANA actions are required by this document.</p><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a name="ack" href="#ack">Acknowledgements</a></h1><p id="rfc.section.9.p.1">This specification is derived from RFC 2396 <a href="#RFC2396" title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</a>, RFC 1808 <a href="#RFC1808" title="Relative Uniform Resource Locators">[RFC1808]</a>, and RFC 1738 <a href="#RFC1738" title="Uniform Resource Locators (URL)">[RFC1738]</a>;
 the acknowledgements in those documents still apply. It also 
incorporates the update (with corrections) for IPv6 literals in the host
 syntax, as defined by Robert M. Hinden, Brian E. Carpenter, and Larry 
Masinter in <a href="#RFC2732" title="Format for Literal IPv6 Addresses in URL's">[RFC2732]</a>.
 In addition, contributions by Gisle Aas, Reese Anschultz, Daniel 
Barclay, Tim Bray, Mike Brown, Rob Cameron, Jeremy Carroll, Dan 
Connolly, Adam M. Costello, John Cowan, Jason Diamond, Martin Duerst, 
Stefan Eissing, Clive D.W. Feather, Al Gilman, Tony Hammond, Elliotte 
Harold, Pat Hayes, Henry Holtzman, Ian B. Jacobs, Michael Kay, John C. 
Klensin, Graham Klyne, Dan Kohn, Bruce Lilly, Andrew Main, Dave McAlpin,
 Ira McDonald, Michael Mealling, Ray Merkert, Stephen Pollei, Julian 
Reschke, Tomas Rokicki, Miles Sabin, Kai Schaetzl, Mark Thomson, Ronald 
Tschalaer, Norm Walsh, Marc Warne, Stuart Williams, and Henry Zongaro 
are gratefully acknowledged.</p><h1 id="rfc.references"><a name="rfc.section.10" href="#rfc.section.10">10.</a> <a href="#rfc.references">References</a></h1><h2 id="rfc.references.1"><a name="rfc.references.1"></a><a href="#rfc.section.10.1">10.1.</a> Normative References</h2><table summary="Normative References" border="0" cellpadding="2">        <tbody><tr><td class="topnowrap"><b><a name="ASCII">[ASCII]</a></b></td><td class="top">American
 National Standards Institute, “Coded Character Set -- 7-bit American 
Standard Code for Information Interchange”, ANSI&nbsp;X3.4, 1986.</td></tr><tr><td class="topnowrap"><b><a name="RFC2234">[RFC2234]</a></b></td><td class="top"><a title="Internet Mail Consortium">Crocker, D.H.</a> and <a title="Demon Internet Ltd">P. Overell</a>, “<a href="http://www.ietf.org/rfc/rfc2234.txt">Augmented BNF for Syntax Specifications: ABNF</a>”, RFC&nbsp;2234, November&nbsp;1997.</td></tr><tr><td class="topnowrap"><b><a name="STD63">[STD63]</a></b></td><td class="top"><a title="Alis Technologies">Yergeau, F.</a>, “<a href="http://www.ietf.org/rfc/rfc3629.txt">UTF-8, a transformation format of ISO 10646</a>”, STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003.</td></tr><tr><td class="topnowrap"><b><a name="UCS">[UCS]</a></b></td><td class="top">International
 Organization for Standardization, “Information Technology - Universal 
Multiple-Octet Coded Character Set (UCS)”, ISO/IEC&nbsp;10646:2003, 
December&nbsp;2003.</td></tr></tbody></table><h2 id="rfc.references.2"><a name="rfc.references.2"></a><a href="#rfc.section.10.2">10.2.</a> Informative References</h2><table summary="Informative References" border="0" cellpadding="2">                                            <tbody><tr><td class="topnowrap"><b><a name="BCP19">[BCP19]</a></b></td><td class="top">Freed, N. and J. Postel, “<a href="http://www.ietf.org/rfc/rfc2978.txt">IANA Charset Registration Procedures</a>”, BCP&nbsp;19, RFC&nbsp;2978, October&nbsp;2000.</td></tr><tr><td class="topnowrap"><b><a name="BCP35">[BCP35]</a></b></td><td class="top"><a title="UUNET Technologies">Petke, R.</a> and <a title="Microsoft Corporation">I. King</a>, “<a href="http://www.ietf.org/rfc/rfc2717.txt">Registration Procedures for URL Scheme Names</a>”, BCP&nbsp;35, RFC&nbsp;2717, November&nbsp;1999.</td></tr><tr><td class="topnowrap"><b><a name="RFC0952">[RFC0952]</a></b></td><td class="top">Harrenstien, K., Stahl, M., and E. Feinler, “<a href="http://www.ietf.org/rfc/rfc952.txt">DoD Internet host table specification</a>”, RFC&nbsp;952, October&nbsp;1985.</td></tr><tr><td class="topnowrap"><b><a name="RFC1034">[RFC1034]</a></b></td><td class="top">Mockapetris, P., “<a href="http://www.ietf.org/rfc/rfc1034.txt">Domain names - concepts and facilities</a>”, STD&nbsp;13, RFC&nbsp;1034, November&nbsp;1987.</td></tr><tr><td class="topnowrap"><b><a name="RFC1123">[RFC1123]</a></b></td><td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://www.ietf.org/rfc/rfc1123.txt">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.</td></tr><tr><td class="topnowrap"><b><a name="RFC1535">[RFC1535]</a></b></td><td class="top"><a title="ACES Research Inc.">Gavron, E.</a>, “<a href="http://www.ietf.org/rfc/rfc1535.txt">A Security Problem and Proposed Correction With Widely Deployed DNS Software</a>”, RFC&nbsp;1535, October&nbsp;1993.</td></tr><tr><td class="topnowrap"><b><a name="RFC1630">[RFC1630]</a></b></td><td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, “<a href="http://www.ietf.org/rfc/rfc1630.txt">Universal
 Resource Identifiers in WWW: A Unifying Syntax for the Expression of 
Names and Addresses of Objects on the Network as used in the World-Wide 
Web</a>”, RFC&nbsp;1630, June&nbsp;1994.</td></tr><tr><td class="topnowrap"><b><a name="RFC1736">[RFC1736]</a></b></td><td class="top"><a title="Information Systems and Technology">Kunze, J.</a>, “<a href="http://www.ietf.org/rfc/rfc1736.txt">Functional Recommendations for Internet Resource Locators</a>”, RFC&nbsp;1736, February&nbsp;1995.</td></tr><tr><td class="topnowrap"><b><a name="RFC1737">[RFC1737]</a></b></td><td class="top"><a title="MIT Laboratory for Computer Science">Sollins, K.</a> and <a title="Xerox Palo Alto Research Center">L. Masinter</a>, “<a href="http://www.ietf.org/rfc/rfc1737.txt">Functional Requirements for Uniform Resource Names</a>”, RFC&nbsp;1737, December&nbsp;1994.</td></tr><tr><td class="topnowrap"><b><a name="RFC1738">[RFC1738]</a></b></td><td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, <a title="Xerox PARC">Masinter, L.</a>, and <a title="University of Minnesota, Computer and Information Services">M. McCahill</a>, “<a href="http://www.ietf.org/rfc/rfc1738.txt">Uniform Resource Locators (URL)</a>”, RFC&nbsp;1738, December&nbsp;1994.</td></tr><tr><td class="topnowrap"><b><a name="RFC1808">[RFC1808]</a></b></td><td class="top"><a title="University of California Irvine, Department of Information and Computer Science">Fielding, R.</a>, “<a href="http://www.ietf.org/rfc/rfc1808.txt">Relative Uniform Resource Locators</a>”, RFC&nbsp;1808, June&nbsp;1995.</td></tr><tr><td class="topnowrap"><b><a name="RFC2046">[RFC2046]</a></b></td><td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://www.ietf.org/rfc/rfc2046.txt">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC&nbsp;2046, November&nbsp;1996.</td></tr><tr><td class="topnowrap"><b><a name="RFC2141">[RFC2141]</a></b></td><td class="top"><a title="AT&amp;T">Moats, R.</a>, “<a href="http://www.ietf.org/rfc/rfc2141.txt">URN Syntax</a>”, RFC&nbsp;2141, May&nbsp;1997.</td></tr><tr><td class="topnowrap"><b><a name="RFC2396">[RFC2396]</a></b></td><td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="University of California, Irvine">Fielding, R.T.</a>, and <a title="Xerox PARC">L. Masinter</a>, “<a href="http://www.ietf.org/rfc/rfc2396.txt">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.</td></tr><tr><td class="topnowrap"><b><a name="RFC2518">[RFC2518]</a></b></td><td class="top"><a title="Microsoft Corporation">Goland, Y.</a>, <a title="Dept. Of Information and Computer
Science, University of California, Irvine">Whitehead, E.</a>, <a title="Netscape">Faizi, A.</a>, <a title="Novell">Carter, S.R.</a>, and <a title="Novell">D. Jensen</a>, “<a href="http://www.ietf.org/rfc/rfc2518.txt">HTTP Extensions for Distributed Authoring -- WEBDAV</a>”, RFC&nbsp;2518, February&nbsp;1999.</td></tr><tr><td class="topnowrap"><b><a name="RFC2557">[RFC2557]</a></b></td><td class="top"><a title="Stockholm University and KTH">Palme, J.</a>, <a title="Microsoft Corporation">Hopmann, A.</a>, and <a title="Lotus Development Corporation">N. Shelness</a>, “<a href="http://www.ietf.org/rfc/rfc2557.txt">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC&nbsp;2557, March&nbsp;1999.</td></tr><tr><td class="topnowrap"><b><a name="RFC2718">[RFC2718]</a></b></td><td class="top"><a title="Xerox Corporation, Palo Alto Research Center">Masinter, L.</a>, <a title="Maxware">Alvestrand, H.</a>, <a title="WebTV Networks, Inc.">Zigmond, D.</a>, and <a title="UUNET Technologies">R. Petke</a>, “<a href="http://www.ietf.org/rfc/rfc2718.txt">Guidelines for new URL Schemes</a>”, RFC&nbsp;2718, November&nbsp;1999.</td></tr><tr><td class="topnowrap"><b><a name="RFC2732">[RFC2732]</a></b></td><td class="top"><a title="Nokia">Hinden, R.M.</a>, <a title="IBM, iCAIR">Carpenter, B.E.</a>, and <a title="AT&amp;T Labs">L. Masinter</a>, “<a href="http://www.ietf.org/rfc/rfc2732.txt">Format for Literal IPv6 Addresses in URL's</a>”, RFC&nbsp;2732, December&nbsp;1999.</td></tr><tr><td class="topnowrap"><b><a name="RFC3305">[RFC3305]</a></b></td><td class="top">Mealling, M. and R. Denenberg, “<a href="http://www.ietf.org/rfc/rfc3305.txt">Report
 from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource 
Identifiers (URIs), URLs, and Uniform Resource Names (URNs): 
Clarifications and Recommendations</a>”, RFC&nbsp;3305, August&nbsp;2002.</td></tr><tr><td class="topnowrap"><b><a name="RFC3490">[RFC3490]</a></b></td><td class="top">Faltstrom, P., Hoffman, P., and A. Costello, “<a href="http://www.ietf.org/rfc/rfc3490.txt">Internationalizing Domain Names in Applications (IDNA)</a>”, RFC&nbsp;3490, March&nbsp;2003.</td></tr><tr><td class="topnowrap"><b><a name="RFC3513">[RFC3513]</a></b></td><td class="top"><a title="Nokia">Hinden, R.</a> and <a title="Cisco Systems, Inc.">S. Deering</a>, “<a href="http://www.ietf.org/rfc/rfc3513.txt">Internet Protocol Version 6 (IPv6) Addressing Architecture</a>”, RFC&nbsp;3513, April&nbsp;2003.</td></tr><tr><td class="topnowrap"><b><a name="Siedzik">[Siedzik]</a></b></td><td class="top">Siedzik, R., “<a href="http://www.giac.org/practical/gsec/Richard_Siedzik_GSEC.pdf">Semantic Attacks: What's in a URL?</a>”, April&nbsp;2001.</td></tr></tbody></table><h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a name="collected-abnf" href="#collected-abnf">Collected ABNF for URI</a></h1><div id="rfc.figure.u.39"></div><pre> URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

 hier-part     = "//" authority path-abempty
               / path-absolute
               / path-rootless
               / path-empty

 URI-reference = URI / relative-ref

 absolute-URI  = scheme ":" hier-part [ "?" query ]

 relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

 relative-part = "//" authority path-abempty
               / path-absolute
               / path-noscheme
               / path-empty

 scheme        = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

 authority     = [ userinfo "@" ] host [ ":" port ]
 userinfo      = *( unreserved / pct-encoded / sub-delims / ":" )
 host          = IP-literal / IPv4address / reg-name
 port          = *DIGIT

 IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"

 IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

 IPv6address   =                            6( h16 ":" ) ls32
               /                       "::" 5( h16 ":" ) ls32
               / [               h16 ] "::" 4( h16 ":" ) ls32
               / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
               / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
               / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
               / [ *4( h16 ":" ) h16 ] "::"              ls32
               / [ *5( h16 ":" ) h16 ] "::"              h16
               / [ *6( h16 ":" ) h16 ] "::"

 h16           = 1*4HEXDIG
 ls32          = ( h16 ":" h16 ) / IPv4address

 IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet

 dec-octet     = DIGIT                 ; 0-9
               / %x31-39 DIGIT         ; 10-99
               / "1" 2DIGIT            ; 100-199
               / "2" %x30-34 DIGIT     ; 200-249
               / "25" %x30-35          ; 250-255

 reg-name      = *( unreserved / pct-encoded / sub-delims )

 path          = path-abempty    ; begins with "/" or is empty
               / path-absolute   ; begins with "/" but not "//"
               / path-noscheme   ; begins with a non-colon segment
               / path-rootless   ; begins with a segment
               / path-empty      ; zero characters

 path-abempty  = *( "/" segment )
 path-absolute = "/" [ segment-nz *( "/" segment ) ]
 path-noscheme = segment-nz-nc *( "/" segment )
 path-rootless = segment-nz *( "/" segment )
 path-empty    = 0&lt;pchar&gt;

 segment       = *pchar
 segment-nz    = 1*pchar
 segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
               ; non-zero-length segment without any colon ":"

 pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

 query         = *( pchar / "/" / "?" )

 fragment      = *( pchar / "/" / "?" )

 pct-encoded   = "%" HEXDIG HEXDIG

 unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
 reserved      = gen-delims / sub-delims
 gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
 sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")"
               / "*" / "+" / "," / ";" / "="
</pre><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a name="regexp" href="#regexp">Parsing a URI Reference with a Regular Expression</a></h1><p id="rfc.section.B.p.1">As
 the "first-match-wins" algorithm is identical to the "greedy" 
disambiguation method used by POSIX regular expressions, it is natural 
and commonplace to use a regular expression for parsing the potential 
five components of a URI reference.</p><p id="rfc.section.B.p.2">The following line is the regular expression for breaking-down a well-formed URI reference into its components.</p><div id="rfc.figure.u.40"></div><pre>   ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
    12            3  4          5       6  7        8 9
</pre><p id="rfc.section.B.p.4">The numbers in the second line above are
 only to assist readability; they indicate the reference points for each
 subexpression (i.e., each paired parenthesis). We refer to the value 
matched for subexpression &lt;n&gt; as $&lt;n&gt;. For example, matching
 the above expression to</p><div id="rfc.figure.u.41"></div><pre>   http://www.ics.uci.edu/pub/ietf/uri/#Related
</pre><p id="rfc.section.B.p.6">results in the following subexpression matches:</p><div id="rfc.figure.u.42"></div><pre>   $1 = http:
   $2 = http
   $3 = //www.ics.uci.edu
   $4 = www.ics.uci.edu
   $5 = /pub/ietf/uri/
   $6 = &lt;undefined&gt;
   $7 = &lt;undefined&gt;
   $8 = #Related
   $9 = Related
</pre><p id="rfc.section.B.p.8">where &lt;undefined&gt; indicates that 
the component is not present, as is the case for the query component in 
the above example. Therefore, we can determine the value of the five 
components as</p><div id="rfc.figure.u.43"></div><pre>   scheme    = $2
   authority = $4
   path      = $5
   query     = $7
   fragment  = $9
</pre><p id="rfc.section.B.p.10">Going in the opposite direction, we can recreate a URI reference from its components by using the algorithm of <a href="#recomposition" title="Component Recomposition">Section&nbsp;5.3</a>.</p><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a name="delimiting" href="#delimiting">Delimiting a URI in Context</a></h1><p id="rfc.section.C.p.1">URIs
 are often transmitted through formats that do not provide a clear 
context for their interpretation. For example, there are many occasions 
when a URI is included in plain text; examples include text sent in 
email, USENET news, and on printed paper. In such cases, it is important
 to be able to delimit the URI from the rest of the text, and in 
particular from punctuation marks that might be mistaken for part of the
 URI.</p><p id="rfc.section.C.p.2">In practice, URIs are delimited in a 
variety of ways, but usually within double-quotes "http://example.com/",
 angle brackets &lt;http://example.com/&gt;, or just by using 
whitespace:</p><div id="rfc.figure.u.44"></div><pre>   http://example.com/
</pre><p id="rfc.section.C.p.4">These wrappers do not form part of the URI.</p><p id="rfc.section.C.p.5">In
 some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have
 to be added to break a long URI across lines. The whitespace should be 
ignored when the URI is extracted.</p><p id="rfc.section.C.p.6">No 
whitespace should be introduced after a hyphen ("-") character. Because 
some typesetters and printers may (erroneously) introduce a hyphen at 
the end of line when breaking it, the interpreter of a URI containing a 
line break immediately after a hyphen should ignore all whitespace 
around the line break and should be aware that the hyphen may or may not
 actually be part of the URI.</p><p id="rfc.section.C.p.7">Using 
&lt;&gt; angle brackets around each URI is especially recommended as a 
delimiting style for a reference that contains embedded whitespace.</p><p id="rfc.section.C.p.8">The
 prefix "URL:" (with or without a trailing space) was formerly 
recommended as a way to help distinguish a URI from other bracketed 
designators, though it is not commonly used in practice and is no longer
 recommended.</p><p id="rfc.section.C.p.9">For robustness, software that
 accepts user-typed URI should attempt to recognize and strip both 
delimiters and embedded whitespace.</p><div id="rfc.figure.u.45"></div><p>For example, the text</p><pre>   Yes, Jim, I found it under "http://www.w3.org/Addressing/",
   but you can probably pick it up from &lt;ftp://foo.example.
   com/rfc/&gt;.  Note the warning in &lt;http://www.ics.uci.edu/pub/
   ietf/uri/historical.html#WARNING&gt;.
</pre><p id="rfc.section.C.p.11">contains the URI references</p><div id="rfc.figure.u.46"></div><pre>   http://www.w3.org/Addressing/
   ftp://foo.example.com/rfc/
   http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING
</pre><h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a name="changes" href="#changes">Changes from RFC 2396</a></h1><h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1.</a>&nbsp;<a name="additions" href="#additions">Additions</a></h2><p id="rfc.section.D.1.p.1">An ABNF rule for URI has been introduced to correspond to one common usage of the term: an absolute URI with optional fragment.</p><p id="rfc.section.D.1.p.2">IPv6
 (and later) literals have been added to the list of possible 
identifiers for the host portion of an authority component, as described
 by <a href="#RFC2732" title="Format for Literal IPv6 Addresses in URL's">[RFC2732]</a>,
 with the addition of "[" and "]" to the reserved set and a version flag
 to anticipate future versions of IP literals. Square brackets are now 
specified as reserved within the authority component and are not allowed
 outside their use as delimiters for an IP literal within host. In order
 to make this change without changing the technical definition of the 
path, query, and fragment components, those rules were redefined to 
directly specify the characters allowed.</p><p id="rfc.section.D.1.p.3">As <a href="#RFC2732" title="Format for Literal IPv6 Addresses in URL's">[RFC2732]</a> defers to <a href="#RFC3513" title="Internet Protocol Version 6 (IPv6) Addressing Architecture">[RFC3513]</a>
 for definition of an IPv6 literal address, which, unfortunately, lacks 
an ABNF description of IPv6address, we created a new ABNF rule for 
IPv6address that matches the text representations defined by Section 2.2
 of <a href="#RFC3513" title="Internet Protocol Version 6 (IPv6) Addressing Architecture">[RFC3513]</a>. Likewise, the definition of IPv4address has been improved in order to limit each decimal octet to the range 0-255.</p><p id="rfc.section.D.1.p.4"> <a href="#comparison" title="Normalization and Comparison">Section&nbsp;6</a>,
 on URI normalization and comparison, has been completely rewritten and 
extended by using input from Tim Bray and discussion within the W3C 
Technical Architecture Group.</p><h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2.</a>&nbsp;<a name="modifications" href="#modifications">Modifications</a></h2><p>The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of <a href="#RFC2234" title="Augmented BNF for Syntax Specifications: ABNF">[RFC2234]</a>.
 This change required all rule names that formerly included underscore 
characters to be renamed with a dash instead. In addition, a number of 
syntax rules have been eliminated or simplified to make the overall 
grammar more comprehensible. Specifications that refer to the obsolete 
grammar rules may be understood by replacing those rules according to 
the following table:</p><table summary="
The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of
.  This change required all rule names that
formerly included underscore characters to be renamed with a dash instead.
In addition, a number of syntax rules have been eliminated or simplified
to make the overall grammar more comprehensible.  Specifications that
refer to the obsolete grammar rules may be understood by replacing those
rules according to the following table:
" border="1" cellpadding="3" cellspacing="0"><thead><tr><th style="text-align: left;" valign="top">obsolete rule</th><th style="text-align: left;" valign="top">translation</th></tr></thead><tbody><tr><td class="top" style="text-align: left;">absoluteURI&nbsp;</td><td class="top" style="text-align: left;">absolute-URI&nbsp;</td></tr><tr><td class="top" style="text-align: left;">relativeURI&nbsp;</td><td class="top" style="text-align: left;">relative-part [ "?" query ]&nbsp;</td></tr><tr><td class="top" style="text-align: left;">hier_part&nbsp;</td><td class="top" style="text-align: left;">( "//" authority path-abempty / path-absolute ) [ "?" query ]&nbsp;</td></tr><tr><td class="top" style="text-align: left;">opaque_part&nbsp;</td><td class="top" style="text-align: left;">path-rootless [ "?" query ]&nbsp;</td></tr><tr><td class="top" style="text-align: left;">net_path&nbsp;</td><td class="top" style="text-align: left;">"//" authority path-abempty&nbsp;</td></tr><tr><td class="top" style="text-align: left;">abs_path&nbsp;</td><td class="top" style="text-align: left;">path-absolute&nbsp;</td></tr><tr><td class="top" style="text-align: left;">rel_path&nbsp;</td><td class="top" style="text-align: left;">path-rootless&nbsp;</td></tr><tr><td class="top" style="text-align: left;">rel_segment&nbsp;</td><td class="top" style="text-align: left;">segment-nz-nc&nbsp;</td></tr><tr><td class="top" style="text-align: left;">reg_name&nbsp;</td><td class="top" style="text-align: left;">reg-name&nbsp;</td></tr><tr><td class="top" style="text-align: left;">server&nbsp;</td><td class="top" style="text-align: left;">authority&nbsp;</td></tr><tr><td class="top" style="text-align: left;">hostport&nbsp;</td><td class="top" style="text-align: left;">host [ ":" port ]&nbsp;</td></tr><tr><td class="top" style="text-align: left;">hostname&nbsp;</td><td class="top" style="text-align: left;">reg-name&nbsp;</td></tr><tr><td class="top" style="text-align: left;">path_segments&nbsp;</td><td class="top" style="text-align: left;">path-abempty&nbsp;</td></tr><tr><td class="top" style="text-align: left;">param&nbsp;</td><td class="top" style="text-align: left;">*&lt;pchar excluding ";"&gt;&nbsp;</td></tr><tr><td class="top" style="text-align: left;">uric&nbsp;</td><td class="top" style="text-align: left;">unreserved / pct-encoded / ";" / "?" / ":" / "@" / "&amp;" / "=" / "+" / "$" / "," / "/"&nbsp;</td></tr><tr><td class="top" style="text-align: left;">uric_no_slash&nbsp;</td><td class="top" style="text-align: left;">unreserved / pct-encoded / ";" / "?" / ":" / "@" / "&amp;" / "=" / "+" / "$" / ","&nbsp;</td></tr><tr><td class="top" style="text-align: left;">mark&nbsp;</td><td class="top" style="text-align: left;">"-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"&nbsp;</td></tr><tr><td class="top" style="text-align: left;">escaped&nbsp;</td><td class="top" style="text-align: left;">pct-encoded&nbsp;</td></tr><tr><td class="top" style="text-align: left;">hex&nbsp;</td><td class="top" style="text-align: left;">HEXDIG&nbsp;</td></tr><tr><td class="top" style="text-align: left;">alphanum&nbsp;</td><td class="top" style="text-align: left;">ALPHA / DIGIT&nbsp;</td></tr></tbody></table><p>Use of the above obsolete rules for the definition of scheme-specific syntax is deprecated.</p><p id="rfc.section.D.2.p.1">Section
 2, on characters, has been rewritten to explain what characters are 
reserved, when they are reserved, and why they are reserved, even when 
they are not used as delimiters by the generic syntax. The mark 
characters that are typically unsafe to decode, including the 
exclamation mark ("!"), asterisk ("*"), single-quote ("'"), and open and
 close parentheses ("(" and ")"), have been moved to the reserved set in
 order to clarify the distinction between reserved and unreserved and, 
hopefully, to answer the most common question of scheme designers. 
Likewise, the section on percent-encoded characters has been rewritten, 
and URI normalizers are now given license to decode any percent-encoded 
octets corresponding to unreserved characters. In general, the terms 
"escaped" and "unescaped" have been replaced with "percent-encoded" and 
"decoded", respectively, to reduce confusion with other forms of escape 
mechanisms.</p><p id="rfc.section.D.2.p.2">The ABNF for URI and 
URI-reference has been redesigned to make them more friendly to LALR 
parsers and to reduce complexity. As a result, the layout form of syntax
 description has been removed, along with the uric, uric_no_slash, 
opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment, 
and mark rules. All references to "opaque" URIs have been replaced with a
 better description of how the path component may be opaque to 
hierarchy. The relativeURI rule has been replaced with relative-ref to 
avoid unnecessary confusion over whether they are a subset of URI. The 
ambiguity regarding the parsing of URI-reference as a URI or a 
relative-ref with a colon in the first segment has been eliminated 
through the use of five separate path matching rules.</p><p id="rfc.section.D.2.p.3">The
 fragment identifier has been moved back into the section on generic 
syntax components and within the URI and relative-ref rules, though it 
remains excluded from absolute-URI. The number sign ("#") character has 
been moved back to the reserved set as a result of reintegrating the 
fragment syntax.</p><p id="rfc.section.D.2.p.4">The ABNF has been 
corrected to allow the path component to be empty. This also allows an 
absolute-URI to consist of nothing after the "scheme:", as is present in
 practice with the "dav:" namespace <a href="#RFC2518" title="HTTP Extensions for Distributed Authoring -- WEBDAV">[RFC2518]</a>
 and with the "about:" scheme used internally by many WWW browser 
implementations. The ambiguity regarding the boundary between authority 
and path has been eliminated through the use of five separate path 
matching rules.</p><p id="rfc.section.D.2.p.5">Registry-based naming 
authorities that use the generic syntax are now defined within the host 
rule. This change allows current implementations, where whatever name 
provided is simply fed to the local name resolution mechanism, to be 
consistent with the specification. It also removes the need to 
re-specify DNS name formats here. Furthermore, it allows the host 
component to contain percent-encoded octets, which is necessary to 
enable internationalized domain names to be provided in URIs, processed 
in their native character encodings at the application layers above URI 
processing, and passed to an IDNA library as a registered name in the 
UTF-8 character encoding. The server, hostport, hostname, domainlabel, 
toplabel, and alphanum rules have been removed.</p><p id="rfc.section.D.2.p.6">The resolving relative references algorithm of <a href="#RFC2396" title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</a> has been rewritten with pseudocode for this revision to improve clarity and fix the following issues: </p><ul><li> <a href="#RFC2396" title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</a> section 5.2, step 6a, failed to account for a base URI with no path.</li><li>Restored the behavior of <a href="#RFC1808" title="Relative Uniform Resource Locators">[RFC1808]</a>
 where, if the reference contains an empty path and a defined query 
component, the target URI inherits the base URI's path component.</li><li>The
 determination of whether a URI reference is a same-document reference 
has been decoupled from the URI parser, simplifying the URI processing 
interface within applications in a way consistent with the internal 
architecture of deployed URI processing implementations. The 
determination is now based on comparison to the base URI after 
transforming a reference to absolute form, rather than on the format of 
the reference itself. This change may result in more references being 
considered "same-document" under this specification than there would be 
under the rules given in RFC 2396, especially when normalization is used
 to reduce aliases. However, it does not change the status of existing 
same-document references.</li><li>Separated the path merge routine into 
two routines: merge, for describing combination of the base URI path 
with a relative-path reference, and remove_dot_segments, for describing 
how to remove the special "." and ".." segments from a composed path. 
The remove_dot_segments algorithm is now applied to all URI reference 
paths in order to match common implementations and to improve the 
normalization of URIs in practice. This change only impacts the parsing 
of abnormal references and same-scheme references wherein the base URI 
has a non-hierarchical path.</li></ul><h1 id="rfc.authors">Authors' Addresses</h1><table summary="Authors" width="99%" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td>&nbsp;</td><td>Tim Berners-Lee</td></tr><tr><td>&nbsp;</td><td>World Wide Web Consortium</td></tr><tr><td>&nbsp;</td><td>Massachusetts Institute of Technology<br>77 Massachusetts Avenue<br></td></tr><tr><td>&nbsp;</td><td>Cambridge, MA&nbsp;02139</td></tr><tr><td>&nbsp;</td><td>USA</td></tr><tr><td class="right"><b>Phone:&nbsp;</b></td><td><a href="tel:+1-617-253-5702"><span class="skype_pnh_print_container">+1-617-253-5702</span><span tabindex="-1" dir="ltr" class="skype_pnh_container"><span class="skype_pnh_mark"> begin_of_the_skype_highlighting</span>&nbsp;<span dir="ltr" title="Chiama questo numero in Stati Uniti d'America con Skype: +16172535702" class="skype_pnh_highlighting_inactive_common"><span skypeaction="skype_dropdown" class="skype_pnh_left_span">&nbsp;&nbsp;</span><span skypeaction="skype_dropdown" title="Opzioni Skype " class="skype_pnh_dropart_span"><span skypeaction="skype_dropdown" style="background-position:-5849px 1px !important;" class="skype_pnh_dropart_flag_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>&nbsp;&nbsp;&nbsp;</span><span class="skype_pnh_textarea_span"><span class="skype_pnh_text_span">+1-617-253-5702</span></span><span class="skype_pnh_right_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>&nbsp;<span class="skype_pnh_mark">end_of_the_skype_highlighting</span></span></a></td></tr><tr><td class="right"><b>Fax:&nbsp;</b></td><td><a href="fax:+1-617-258-5999">+1-617-258-5999</a></td></tr><tr><td class="right"><b>EMail:&nbsp;</b></td><td><a>timbl@w3.org</a></td></tr><tr><td class="right"><b>URI:&nbsp;</b></td><td><a href="http://www.w3.org/People/Berners-Lee/">http://www.w3.org/People/Berners-Lee/</a></td></tr><tr><td>&nbsp;</td><td></td></tr><tr><td>&nbsp;</td><td>Roy T. Fielding</td></tr><tr><td>&nbsp;</td><td>Day Software</td></tr><tr><td>&nbsp;</td><td>5251 California Ave., Suite 110<br></td></tr><tr><td>&nbsp;</td><td>Irvine, CA&nbsp;92617</td></tr><tr><td>&nbsp;</td><td>USA</td></tr><tr><td class="right"><b>Phone:&nbsp;</b></td><td><a href="tel:+1-949-679-2960"><span class="skype_pnh_print_container">+1-949-679-2960</span><span tabindex="-1" dir="ltr" class="skype_pnh_container"><span class="skype_pnh_mark"> begin_of_the_skype_highlighting</span>&nbsp;<span dir="ltr" title="Chiama questo numero in Stati Uniti d'America con Skype: +19496792960" class="skype_pnh_highlighting_inactive_common"><span skypeaction="skype_dropdown" class="skype_pnh_left_span">&nbsp;&nbsp;</span><span skypeaction="skype_dropdown" title="Opzioni Skype " class="skype_pnh_dropart_span"><span skypeaction="skype_dropdown" style="background-position:-5849px 1px !important;" class="skype_pnh_dropart_flag_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>&nbsp;&nbsp;&nbsp;</span><span class="skype_pnh_textarea_span"><span class="skype_pnh_text_span">+1-949-679-2960</span></span><span class="skype_pnh_right_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>&nbsp;<span class="skype_pnh_mark">end_of_the_skype_highlighting</span></span></a></td></tr><tr><td class="right"><b>Fax:&nbsp;</b></td><td><a href="fax:+1-949-679-2972">+1-949-679-2972</a></td></tr><tr><td class="right"><b>EMail:&nbsp;</b></td><td><a>fielding@gbiv.com</a></td></tr><tr><td class="right"><b>URI:&nbsp;</b></td><td><a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></td></tr><tr><td>&nbsp;</td><td></td></tr><tr><td>&nbsp;</td><td>Larry Masinter</td></tr><tr><td>&nbsp;</td><td>Adobe Systems Incorporated</td></tr><tr><td>&nbsp;</td><td>345 Park Ave<br></td></tr><tr><td>&nbsp;</td><td>San Jose, CA&nbsp;95110</td></tr><tr><td>&nbsp;</td><td>USA</td></tr><tr><td class="right"><b>Phone:&nbsp;</b></td><td><a href="tel:+1-408-536-3024"><span class="skype_pnh_print_container">+1-408-536-3024</span><span tabindex="-1" dir="ltr" class="skype_pnh_container"><span class="skype_pnh_mark"> begin_of_the_skype_highlighting</span>&nbsp;<span dir="ltr" title="Chiama questo numero in Stati Uniti d'America con Skype: +14085363024" class="skype_pnh_highlighting_inactive_common"><span skypeaction="skype_dropdown" class="skype_pnh_left_span">&nbsp;&nbsp;</span><span skypeaction="skype_dropdown" title="Opzioni Skype " class="skype_pnh_dropart_span"><span skypeaction="skype_dropdown" style="background-position:-5849px 1px !important;" class="skype_pnh_dropart_flag_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>&nbsp;&nbsp;&nbsp;</span><span class="skype_pnh_textarea_span"><span class="skype_pnh_text_span">+1-408-536-3024</span></span><span class="skype_pnh_right_span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></span>&nbsp;<span class="skype_pnh_mark">end_of_the_skype_highlighting</span></span></a></td></tr><tr><td class="right"><b>EMail:&nbsp;</b></td><td><a>LMM@acm.org</a></td></tr><tr><td class="right"><b>URI:&nbsp;</b></td><td><a href="http://larry.masinter.net/">http://larry.masinter.net/</a></td></tr><tr><td>&nbsp;</td><td></td></tr></tbody></table><h1><a name="rfc.ipr" href="#rfc.ipr">Intellectual Property Statement</a></h1><p>The
 IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in this
 document or the extent to which any license under such rights might or 
might not be available; nor does it represent that it has made any 
independent effort to identify any such rights. Information on the 
procedures with respect to rights in RFC documents can be found in BCP 
78 and BCP 79.</p><p>Copies of IPR disclosures made to the IETF 
Secretariat and any assurances of licenses to be made available, or the 
result of an attempt made to obtain a general license or permission for 
the use of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
&lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.</p><p>The
 IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary rights 
that may cover technology that may be required to implement this 
standard. Please address the information to the IETF at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.</p><h1><a name="rfc.disclaimer" href="#rfc.disclaimer">Disclaimer of Validity</a></h1><p>This
 document and the information contained herein are provided on an “AS 
IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 
FITNESS FOR A PARTICULAR PURPOSE.</p><h1><a name="rfc.copyright" href="#rfc.copyright">Copyright Statement</a></h1><p>Copyright
 © The Internet Society (2005). This document is subject to the rights, 
licenses and restrictions contained in BCP 78, and except as set forth 
therein, the authors retain all their rights.</p><h1>Acknowledgement</h1><p>Funding for the RFC Editor function is currently provided by the Internet Society.</p><h1 id="rfc.index"><a href="#rfc.index">Index</a></h1><p class="noprint"><a href="#rfc.index.A">A </a><a href="#rfc.index.B">B </a><a href="#rfc.index.C">C </a><a href="#rfc.index.D">D </a><a href="#rfc.index.F">F </a><a href="#rfc.index.G">G </a><a href="#rfc.index.H">H </a><a href="#rfc.index.I">I </a><a href="#rfc.index.L">L </a><a href="#rfc.index.M">M </a><a href="#rfc.index.N">N </a><a href="#rfc.index.P">P </a><a href="#rfc.index.Q">Q </a><a href="#rfc.index.R">R </a><a href="#rfc.index.S">S </a><a href="#rfc.index.T">T </a><a href="#rfc.index.U">U </a></p><ul class="ind"><li class="indline0"><a name="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"><li class="indline1">ABNF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.21"><b>1.3.</b></a></li><li class="indline1">absolute&nbsp;&nbsp;<a class="iref" href="#rfc.iref.134"><b>4.3.</b></a></li><li class="indline1">absolute-path&nbsp;&nbsp;<a class="iref" href="#rfc.iref.129"><b>4.2.</b></a></li><li class="indline1">absolute-URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.135"><b>4.3.</b></a></li><li class="indline1">access&nbsp;&nbsp;<a class="iref" href="#rfc.iref.13"><b>1.2.2.</b></a></li><li class="indline1">authority&nbsp;&nbsp;<a class="iref" href="#rfc.iref.49">3.</a>, <a class="iref" href="#rfc.iref.65"><b>3.2.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind"><li class="indline1">base URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.143"><b>5.1.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"><li class="indline1">character&nbsp;&nbsp;<a class="iref" href="#rfc.iref.1"><b>1.</b></a></li><li class="indline1">character encoding&nbsp;&nbsp;<a class="iref" href="#rfc.iref.3"><b>1.</b></a></li><li class="indline1">characters&nbsp;&nbsp;<a class="iref" href="#rfc.iref.30"><b>2.</b></a></li><li class="indline1">coded character set&nbsp;&nbsp;<a class="iref" href="#rfc.iref.2"><b>1.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind"><li class="indline1">dec-octet&nbsp;&nbsp;<a class="iref" href="#rfc.iref.88"><b>3.2.2.</b></a></li><li class="indline1">dereference&nbsp;&nbsp;<a class="iref" href="#rfc.iref.15"><b>1.2.2.</b></a></li><li class="indline1">dot-segments&nbsp;&nbsp;<a class="iref" href="#rfc.iref.116"><b>3.3.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul class="ind"><li class="indline1">fragment&nbsp;&nbsp;<a class="iref" href="#rfc.iref.52">3.</a>, <a class="iref" href="#rfc.iref.120"><b>3.5.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"><li class="indline1">gen-delims&nbsp;&nbsp;<a class="iref" href="#rfc.iref.35"><b>2.2.</b></a></li><li class="indline1">generic syntax&nbsp;&nbsp;<a class="iref" href="#rfc.iref.7"><b>1.1.1.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind"><li class="indline1">h16&nbsp;&nbsp;<a class="iref" href="#rfc.iref.78"><b>3.2.2.</b></a></li><li class="indline1">hierarchical&nbsp;&nbsp;<a class="iref" href="#rfc.iref.19"><b>1.2.3.</b></a></li><li class="indline1">hier-part&nbsp;&nbsp;<a class="iref" href="#rfc.iref.43"><b>3.</b></a></li><li class="indline1">host&nbsp;&nbsp;<a class="iref" href="#rfc.iref.72"><b>3.2.2.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"><li class="indline1">identifier&nbsp;&nbsp;<a class="iref" href="#rfc.iref.6"><b>1.1.</b></a></li><li class="indline1">IP-literal&nbsp;&nbsp;<a class="iref" href="#rfc.iref.75"><b>3.2.2.</b></a></li><li class="indline1">IPv4&nbsp;&nbsp;<a class="iref" href="#rfc.iref.86"><b>3.2.2.</b></a></li><li class="indline1">IPv4address&nbsp;&nbsp;<a class="iref" href="#rfc.iref.87"><b>3.2.2.</b></a></li><li class="indline1">IPv6&nbsp;&nbsp;<a class="iref" href="#rfc.iref.74"><b>3.2.2.</b></a></li><li class="indline1">IPv6address&nbsp;&nbsp;<a class="iref" href="#rfc.iref.76"><b>3.2.2.</b></a></li><li class="indline1">IPvFuture&nbsp;&nbsp;<a class="iref" href="#rfc.iref.79"><b>3.2.2.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind"><li class="indline1">locator&nbsp;&nbsp;<a class="iref" href="#rfc.iref.10"><b>1.1.3.</b></a></li><li class="indline1">ls32&nbsp;&nbsp;<a class="iref" href="#rfc.iref.77"><b>3.2.2.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind"><li class="indline1">merge&nbsp;&nbsp;<a class="iref" href="#rfc.iref.144"><b>5.2.3.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul class="ind"><li class="indline1">name&nbsp;&nbsp;<a class="iref" href="#rfc.iref.11"><b>1.1.3.</b></a></li><li class="indline1">network-path&nbsp;&nbsp;<a class="iref" href="#rfc.iref.128"><b>4.2.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"><li class="indline1">path&nbsp;&nbsp;<a class="iref" href="#rfc.iref.50">3.</a>, <a class="iref" href="#rfc.iref.96"><b>3.3.</b></a><ul class="ind"><li class="indline1">path-abempty&nbsp;&nbsp;<a class="iref" href="#rfc.iref.97"><b>3.3.</b></a></li><li class="indline1">path-absolute&nbsp;&nbsp;<a class="iref" href="#rfc.iref.98"><b>3.3.</b></a></li><li class="indline1">path-empty&nbsp;&nbsp;<a class="iref" href="#rfc.iref.101"><b>3.3.</b></a></li><li class="indline1">path-noscheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.99"><b>3.3.</b></a></li><li class="indline1">path-rootless&nbsp;&nbsp;<a class="iref" href="#rfc.iref.100"><b>3.3.</b></a></li></ul></li><li class="indline1">path-abempty&nbsp;&nbsp;<a class="iref" href="#rfc.iref.44">3.</a></li><li class="indline1">path-absolute&nbsp;&nbsp;<a class="iref" href="#rfc.iref.45">3.</a></li><li class="indline1">path-empty&nbsp;&nbsp;<a class="iref" href="#rfc.iref.47">3.</a></li><li class="indline1">path-rootless&nbsp;&nbsp;<a class="iref" href="#rfc.iref.46">3.</a></li><li class="indline1">pchar&nbsp;&nbsp;<a class="iref" href="#rfc.iref.105"><b>3.3.</b></a></li><li class="indline1">pct-encoded&nbsp;&nbsp;<a class="iref" href="#rfc.iref.32"><b>2.1.</b></a></li><li class="indline1">percent-encoding&nbsp;&nbsp;<a class="iref" href="#rfc.iref.31"><b>2.1.</b></a></li><li class="indline1">port&nbsp;&nbsp;<a class="iref" href="#rfc.iref.94"><b>3.2.3.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.Q" href="#rfc.index.Q"><b>Q</b></a><ul class="ind"><li class="indline1">query&nbsp;&nbsp;<a class="iref" href="#rfc.iref.51">3.</a>, <a class="iref" href="#rfc.iref.117"><b>3.4.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"><li class="indline1">registered name&nbsp;&nbsp;<a class="iref" href="#rfc.iref.92"><b>3.2.2.</b></a></li><li class="indline1">reg-name&nbsp;&nbsp;<a class="iref" href="#rfc.iref.91"><b>3.2.2.</b></a></li><li class="indline1">relative&nbsp;&nbsp;<a class="iref" href="#rfc.iref.20"><b>1.2.3.</b></a>, <a class="iref" href="#rfc.iref.141">5.</a></li><li class="indline1">relative-path&nbsp;&nbsp;<a class="iref" href="#rfc.iref.130"><b>4.2.</b></a></li><li class="indline1">relative-ref&nbsp;&nbsp;<a class="iref" href="#rfc.iref.127"><b>4.2.</b></a></li><li class="indline1">remove_dot_segments&nbsp;&nbsp;<a class="iref" href="#rfc.iref.145"><b>5.2.4.</b></a></li><li class="indline1">representation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.17"><b>1.2.2.</b></a></li><li class="indline1">reserved&nbsp;&nbsp;<a class="iref" href="#rfc.iref.34"><b>2.2.</b></a></li><li class="indline1">resolution&nbsp;&nbsp;<a class="iref" href="#rfc.iref.14"><b>1.2.2.</b></a>, <a class="iref" href="#rfc.iref.142">5.</a></li><li class="indline1">resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.5"><b>1.1.</b></a></li><li class="indline1">retrieval&nbsp;&nbsp;<a class="iref" href="#rfc.iref.16"><b>1.2.2.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind"><li class="indline1">same-document&nbsp;&nbsp;<a class="iref" href="#rfc.iref.139"><b>4.4.</b></a></li><li class="indline1">sameness&nbsp;&nbsp;<a class="iref" href="#rfc.iref.18"><b>1.2.2.</b></a></li><li class="indline1">scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.48">3.</a>, <a class="iref" href="#rfc.iref.63"><b>3.1.</b></a></li><li class="indline1">segment&nbsp;&nbsp;<a class="iref" href="#rfc.iref.102"><b>3.3.</b></a><ul class="ind"><li class="indline1">segment-nz&nbsp;&nbsp;<a class="iref" href="#rfc.iref.103"><b>3.3.</b></a></li><li class="indline1">segment-nz-nc&nbsp;&nbsp;<a class="iref" href="#rfc.iref.104"><b>3.3.</b></a></li></ul></li><li class="indline1">sub-delims&nbsp;&nbsp;<a class="iref" href="#rfc.iref.36"><b>2.2.</b></a></li><li class="indline1">suffix&nbsp;&nbsp;<a class="iref" href="#rfc.iref.140"><b>4.5.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind"><li class="indline1">transcription&nbsp;&nbsp;<a class="iref" href="#rfc.iref.12"><b>1.2.1.</b></a></li></ul></li><li class="indline0"><a name="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind"><li class="indline1">uniform&nbsp;&nbsp;<a class="iref" href="#rfc.iref.4"><b>1.1.</b></a></li><li class="indline1">unreserved&nbsp;&nbsp;<a class="iref" href="#rfc.iref.40"><b>2.3.</b></a></li><li class="indline1">URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.42"><b>3.</b></a></li><li class="indline1">URI grammar&nbsp;&nbsp;<ul class="ind"><li class="indline1">absolute-URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.136"><b>4.3.</b></a></li><li class="indline1">ALPHA&nbsp;&nbsp;<a class="iref" href="#rfc.iref.22"><b>1.3.</b></a></li><li class="indline1">authority&nbsp;&nbsp;<a class="iref" href="#rfc.iref.55">3.</a>, <a class="iref" href="#rfc.iref.66"><b>3.2.</b></a></li><li class="indline1">CR&nbsp;&nbsp;<a class="iref" href="#rfc.iref.23"><b>1.3.</b></a></li><li class="indline1">dec-octet&nbsp;&nbsp;<a class="iref" href="#rfc.iref.90"><b>3.2.2.</b></a></li><li class="indline1">DIGIT&nbsp;&nbsp;<a class="iref" href="#rfc.iref.24"><b>1.3.</b></a></li><li class="indline1">DQUOTE&nbsp;&nbsp;<a class="iref" href="#rfc.iref.25"><b>1.3.</b></a></li><li class="indline1">fragment&nbsp;&nbsp;<a class="iref" href="#rfc.iref.58">3.</a>, <a class="iref" href="#rfc.iref.121"><b>3.5.</b></a>, <a class="iref" href="#rfc.iref.133">4.2.</a></li><li class="indline1">gen-delims&nbsp;&nbsp;<a class="iref" href="#rfc.iref.38"><b>2.2.</b></a></li><li class="indline1">h16&nbsp;&nbsp;<a class="iref" href="#rfc.iref.85"><b>3.2.2.</b></a></li><li class="indline1">HEXDIG&nbsp;&nbsp;<a class="iref" href="#rfc.iref.26"><b>1.3.</b></a></li><li class="indline1">hier-part&nbsp;&nbsp;<a class="iref" href="#rfc.iref.56"><b>3.</b></a></li><li class="indline1">host&nbsp;&nbsp;<a class="iref" href="#rfc.iref.68">3.2.</a>, <a class="iref" href="#rfc.iref.73"><b>3.2.2.</b></a></li><li class="indline1">IP-literal&nbsp;&nbsp;<a class="iref" href="#rfc.iref.80"><b>3.2.2.</b></a></li><li class="indline1">IPv4address&nbsp;&nbsp;<a class="iref" href="#rfc.iref.89"><b>3.2.2.</b></a></li><li class="indline1">IPv6address&nbsp;&nbsp;<a class="iref" href="#rfc.iref.81">3.2.2.</a>, <a class="iref" href="#rfc.iref.83"><b>3.2.2.</b></a></li><li class="indline1">IPvFuture&nbsp;&nbsp;<a class="iref" href="#rfc.iref.82"><b>3.2.2.</b></a></li><li class="indline1">LF&nbsp;&nbsp;<a class="iref" href="#rfc.iref.27"><b>1.3.</b></a></li><li class="indline1">ls32&nbsp;&nbsp;<a class="iref" href="#rfc.iref.84"><b>3.2.2.</b></a></li><li class="indline1">OCTET&nbsp;&nbsp;<a class="iref" href="#rfc.iref.28"><b>1.3.</b></a></li><li class="indline1">path&nbsp;&nbsp;<a class="iref" href="#rfc.iref.106"><b>3.3.</b></a></li><li class="indline1">path-abempty&nbsp;&nbsp;<a class="iref" href="#rfc.iref.59">3.</a>, <a class="iref" href="#rfc.iref.107"><b>3.3.</b></a></li><li class="indline1">path-absolute&nbsp;&nbsp;<a class="iref" href="#rfc.iref.60">3.</a>, <a class="iref" href="#rfc.iref.108"><b>3.3.</b></a></li><li class="indline1">path-empty&nbsp;&nbsp;<a class="iref" href="#rfc.iref.62">3.</a>, <a class="iref" href="#rfc.iref.111"><b>3.3.</b></a></li><li class="indline1">path-noscheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.109"><b>3.3.</b></a></li><li class="indline1">path-rootless&nbsp;&nbsp;<a class="iref" href="#rfc.iref.61">3.</a>, <a class="iref" href="#rfc.iref.110"><b>3.3.</b></a></li><li class="indline1">pchar&nbsp;&nbsp;<a class="iref" href="#rfc.iref.115"><b>3.3.</b></a>, <a class="iref" href="#rfc.iref.119">3.4.</a>, <a class="iref" href="#rfc.iref.122">3.5.</a></li><li class="indline1">pct-encoded&nbsp;&nbsp;<a class="iref" href="#rfc.iref.33"><b>2.1.</b></a></li><li class="indline1">port&nbsp;&nbsp;<a class="iref" href="#rfc.iref.69">3.2.</a>, <a class="iref" href="#rfc.iref.95"><b>3.2.3.</b></a></li><li class="indline1">query&nbsp;&nbsp;<a class="iref" href="#rfc.iref.57">3.</a>, <a class="iref" href="#rfc.iref.118"><b>3.4.</b></a>, <a class="iref" href="#rfc.iref.132">4.2.</a>, <a class="iref" href="#rfc.iref.138">4.3.</a></li><li class="indline1">reg-name&nbsp;&nbsp;<a class="iref" href="#rfc.iref.93"><b>3.2.2.</b></a></li><li class="indline1">relative-ref&nbsp;&nbsp;<a class="iref" href="#rfc.iref.126">4.1.</a>, <a class="iref" href="#rfc.iref.131"><b>4.2.</b></a></li><li class="indline1">reserved&nbsp;&nbsp;<a class="iref" href="#rfc.iref.37"><b>2.2.</b></a></li><li class="indline1">scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.54">3.</a>, <a class="iref" href="#rfc.iref.64"><b>3.1.</b></a>, <a class="iref" href="#rfc.iref.137">4.3.</a></li><li class="indline1">segment&nbsp;&nbsp;<a class="iref" href="#rfc.iref.112"><b>3.3.</b></a></li><li class="indline1">segment-nz&nbsp;&nbsp;<a class="iref" href="#rfc.iref.113"><b>3.3.</b></a></li><li class="indline1">segment-nz-nc&nbsp;&nbsp;<a class="iref" href="#rfc.iref.114"><b>3.3.</b></a></li><li class="indline1">SP&nbsp;&nbsp;<a class="iref" href="#rfc.iref.29"><b>1.3.</b></a></li><li class="indline1">sub-delims&nbsp;&nbsp;<a class="iref" href="#rfc.iref.39"><b>2.2.</b></a></li><li class="indline1">unreserved&nbsp;&nbsp;<a class="iref" href="#rfc.iref.41"><b>2.3.</b></a></li><li class="indline1">URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.53"><b>3.</b></a>, <a class="iref" href="#rfc.iref.125">4.1.</a></li><li class="indline1">URI-reference&nbsp;&nbsp;<a class="iref" href="#rfc.iref.124"><b>4.1.</b></a></li><li class="indline1">userinfo&nbsp;&nbsp;<a class="iref" href="#rfc.iref.67">3.2.</a>, <a class="iref" href="#rfc.iref.71"><b>3.2.1.</b></a></li></ul></li><li class="indline1">URI-reference&nbsp;&nbsp;<a class="iref" href="#rfc.iref.123"><b>4.1.</b></a></li><li class="indline1">URL&nbsp;&nbsp;<a class="iref" href="#rfc.iref.8"><b>1.1.3.</b></a></li><li class="indline1">URN&nbsp;&nbsp;<a class="iref" href="#rfc.iref.9"><b>1.1.3.</b></a></li><li class="indline1">userinfo&nbsp;&nbsp;<a class="iref" href="#rfc.iref.70"><b>3.2.1.</b></a></li></ul></li></ul></body></html>